Hi Jim,
It's been a while, since I sent the patch. Any objections about merging?
Is v4.11 kernel still a valid baseline or for the next releases or we should use v4.14? When is that transition and next release supposed to happen?
Best regards, Marcinsob., 23 cze 2018 o 08:18 Marcin Wojtas mw@semihalf.com napisał(a):
Hi,
I'm sending a patch that is applicable on top of the kernel sig-altarch7-aarch64 branch. It enables ACPI support for the Marvell Armada7k8k NIC - this required backporting very big amount of patches (all merged upstream), hence I decided to attach the single commit, instead of issueing 'git send-email' of it.
Despite many attempts I wasn't able to build entire rpm package with the mock build utility, however I managed to test the clean kernel v4.11 with applied all patches and built with updated .config. Please let know if this patch is sufficient and can be merged.
Thanks, Marcin
On 07/30/2018 07:00 AM, Marcin Wojtas wrote:
Hi Jim,
It's been a while, since I sent the patch. Any objections about merging?
Is v4.11 kernel still a valid baseline or for the next releases or we should use v4.14? When is that transition and next release supposed to happen?
The current version of the supported kernel is 4.14, so this would need to be updated to support the 4.14 tree.
Best regards, Marcinsob., 23 cze 2018 o 08:18 Marcin Wojtas mw@semihalf.com napisał(a):
Hi,
I'm sending a patch that is applicable on top of the kernel sig-altarch7-aarch64 branch. It enables ACPI support for the Marvell Armada7k8k NIC - this required backporting very big amount of patches (all merged upstream), hence I decided to attach the single commit, instead of issueing 'git send-email' of it.
Once we got to 4.14, there didn't seem to be a demand for the sig-altarch kernel to continue so I left it at the previous version.
From the sounds of things, you still need it for this to work?
Despite many attempts I wasn't able to build entire rpm package with the mock build utility, however I managed to test the clean kernel v4.11 with applied all patches and built with updated .config. Please let know if this patch is sufficient and can be merged.
I'm guessing no unless it patches/builds against 4.14 as well. I'll see about updating the sig-altarch tree so that we can test there.
Hi Jim,
wt., 31 lip 2018 o 18:09 Jim Perrin jperrin@centos.org napisał(a):
On 07/30/2018 07:00 AM, Marcin Wojtas wrote:
Hi Jim,
It's been a while, since I sent the patch. Any objections about merging?
Is v4.11 kernel still a valid baseline or for the next releases or we should use v4.14? When is that transition and next release supposed to happen?
The current version of the supported kernel is 4.14, so this would need to be updated to support the 4.14 tree.
There is still a gap between vanilla v4.14 version of the driver and the upstream commits that allow to use it with ACPI (although much smaller than for v4.11). What is a procedure of providing you the patches?
Best regards, Marcinsob., 23 cze 2018 o 08:18 Marcin Wojtas mw@semihalf.com napisał(a):
Hi,
I'm sending a patch that is applicable on top of the kernel sig-altarch7-aarch64 branch. It enables ACPI support for the Marvell Armada7k8k NIC - this required backporting very big amount of patches (all merged upstream), hence I decided to attach the single commit, instead of issueing 'git send-email' of it.
Once we got to 4.14, there didn't seem to be a demand for the sig-altarch kernel to continue so I left it at the previous version. From the sounds of things, you still need it for this to work?
Is v4.14-based Centos an official version to support aarch64? If yes, I'd complement this version with the needed patches.
Btw. if I google 'Centos aarch64' the links point to the altarch/7 images. What is their kernel base then? In other words, where should one search for most recent image of aarch64 images? Is there any public release schedule available?
About sig-altarch tree, I'd need to make sure internally. From your perspective, would it be recommended?
Despite many attempts I wasn't able to build entire rpm package with the mock build utility, however I managed to test the clean kernel v4.11 with applied all patches and built with updated .config. Please let know if this patch is sufficient and can be merged.
I'm guessing no unless it patches/builds against 4.14 as well. I'll see about updating the sig-altarch tree so that we can test there.
For sure I need to send updated patch list for v4.14. Please see my question above.
Thanks, Marcin
Hi Jim,
Would it be possible, that you take a look at my questions form the previous email?
Thanks in advance, Marcin
śr., 1 sie 2018 o 17:11 Marcin Wojtas mw@semihalf.com napisał(a):
Hi Jim,
wt., 31 lip 2018 o 18:09 Jim Perrin jperrin@centos.org napisał(a):
On 07/30/2018 07:00 AM, Marcin Wojtas wrote:
Hi Jim,
It's been a while, since I sent the patch. Any objections about merging?
Is v4.11 kernel still a valid baseline or for the next releases or we should use v4.14? When is that transition and next release supposed to happen?
The current version of the supported kernel is 4.14, so this would need to be updated to support the 4.14 tree.
There is still a gap between vanilla v4.14 version of the driver and the upstream commits that allow to use it with ACPI (although much smaller than for v4.11). What is a procedure of providing you the patches?
Best regards, Marcinsob., 23 cze 2018 o 08:18 Marcin Wojtas mw@semihalf.com napisał(a):
Hi,
I'm sending a patch that is applicable on top of the kernel sig-altarch7-aarch64 branch. It enables ACPI support for the Marvell Armada7k8k NIC - this required backporting very big amount of patches (all merged upstream), hence I decided to attach the single commit, instead of issueing 'git send-email' of it.
Once we got to 4.14, there didn't seem to be a demand for the sig-altarch kernel to continue so I left it at the previous version. From the sounds of things, you still need it for this to work?
Is v4.14-based Centos an official version to support aarch64? If yes, I'd complement this version with the needed patches.
Btw. if I google 'Centos aarch64' the links point to the altarch/7 images. What is their kernel base then? In other words, where should one search for most recent image of aarch64 images? Is there any public release schedule available?
About sig-altarch tree, I'd need to make sure internally. From your perspective, would it be recommended?
Despite many attempts I wasn't able to build entire rpm package with the mock build utility, however I managed to test the clean kernel v4.11 with applied all patches and built with updated .config. Please let know if this patch is sufficient and can be merged.
I'm guessing no unless it patches/builds against 4.14 as well. I'll see about updating the sig-altarch tree so that we can test there.
For sure I need to send updated patch list for v4.14. Please see my question above.
Thanks, Marcin
Hi Jim,
I've prepared list of mainline patches, that smoothely apply onto v4.14 baseline. The NIC is working with ACPI as expected. Because it's not clear to me, how patches should be submitted (please see my questions from previous emails), below you can find a full list.
Please let know, how can we proceed from here and how possibly could I test real Centos image with patches applied.
Thanks, Marcin
====== LIST of MVPP2 Patches ====== 38c5eb93aca9 net: mvpp2: remove useless goto (v4.15-rc1) 2d1d7df8a365 net: mvpp2: set the Rx FIFO size depending on the port speeds for PPv2.2 (v4.15-rc1) 7c10f9742d76 net: mvpp2: initialize the Tx FIFO size (v4.15-rc1) 1d7d15d79fb4 net: mvpp2: initialize the RSS tables (v4.15-rc1) 1d17db08c056 net: mvpp2: limit TSO segments and use stop/wake thresholds (v4.15-rc1) 02856a3ba633 net: mvpp2: use the aggr txq size define everywhere (v4.15-rc1) 6eb5d375cefc net: mvpp2: simplify the Tx desc set DMA logic (v4.15-rc1) 118d6298f6f0 net: mvpp2: add ethtool GOP statistics (v4.15-rc1) e5c500eb298a net: mvpp2: fix GOP statistics loop start and stop conditions (v4.15-rc1) ba2d8d887d96 net: mvpp2: fix the txq_init error path (v4.15-rc2) 26146b0e6b68 net: mvpp2: cleanup probed ports in the probe error path (v4.15-rc2) e749aca84b10 net: mvpp2: do not disable GMAC padding (v4.15-rc2) 76e583c5f50e net: mvpp2: check ethtool sets the Tx ring size is to a valid min value (v4.15-rc2) a154f8e399a0 net: mvpp2: allocate zeroed tx descriptors (v4.15-rc3) 8a7b741e76cd net: mvpp2: fix the RSS table entry offset (v4.15-rc3) b70d4a5195c7 net: mvpp2: only free the TSO header buffers when it was allocated (v4.16-rc1) 7cf87e4a5c2b net: mvpp2: split the max ring size from the default one (v4.16-rc1) 385c284fee84 net: mvpp2: align values in ethtool get_coalesce (v4.16-rc1) 24b28ccb8575 net: mvpp2: report the tx-usec coalescing information to ethtool (v4.16-rc1) 86162281c25f net: mvpp2: adjust the coalescing parameters (v4.16-rc1) babe2dbb28e7 device property: Introduce fwnode_get_mac_address() (v4.16-rc1) b28f263b8670 device property: Introduce fwnode_get_phy_mode() (v4.16-rc1) 7c6c57f2ab2c device property: Introduce fwnode_irq_get() (v4.16-rc1) 3395de96ae59 device property: Allow iterating over available child fwnodes (v4.16-rc1) bf147153d7f4 net: mvpp2: simplify maintaining enabled ports' list (v4.16-rc1) 248122212f68 net: mvpp2: use device_*/fwnode_* APIs instead of of_* (v4.16-rc1) a75edc7c2eab net: mvpp2: enable ACPI support in the driver (v4.16-rc1) 7ac8ff95f48c mvpp2: fix multicast address filter (v4.16-rc3) 56beda3db602 net: mvpp2: Add hardware offloading for VLAN filtering (v4.17-rc1) 01d049366529 net: mvpp2: use the same buffer pool for all ports (v4.17-rc1) effbf5f58d64 net: mvpp2: update the BM buffer free/destroy logic (v4.17-rc1) 93ff130f1c2b net: mvpp2: use a data size of 10kB for Tx FIFO on port 0 (v4.17-rc1) 381c56712db4 net: mvpp2: enable UDP/TCP checksum over IPv6 (v4.17-rc1) 576193f2d579 net: mvpp2: jumbo frames support (v4.17-rc1) 6e61e10a8a96 net: mvpp2: mvpp2_check_hw_buf_num() can be static (v4.17-rc1) ce2a27c761ac net: mvpp2: Simplify MAC filtering function parameters (v4.17-rc1) 10fea26ce2aa net: mvpp2: Add support for unicast filtering (v4.17-rc1) e2e031640b3a net: mvpp2: use correct index on array mvpp2_pools (v4.17-rc1) 47e0e14eb1a6 net: mvpp2: Make mvpp2_prs_hw_read a parser entry init function (v4.17-rc1) 0c6d9b44145d net: mvpp2: Don't use dynamic allocs for local variables (v4.17-rc1) cdcfeb0fb473 net: mvpp2: Use relaxed I/O in data path (v4.17-rc1) 3d92f0b58206 net: mvpp2: Fix parser entry init boundary check (v4.17-rc1) 982e05001c47 net: mvpp2: Fix TCAM filter reserved range (v4.17-rc2) da42bb271305 net: mvpp2: Fix DMA address mask size (v4.17-rc2) 45f972adb7f4 net: mvpp2: Fix clk error path in mvpp2_probe (v4.17-rc4) 9af771ced473 net: mvpp2: Fix clock resource by adding missing mg_core_clk (v4.17-rc4) ====== END OF LIST =============
pon., 13 sie 2018 o 10:50 Marcin Wojtas mw@semihalf.com napisał(a):
Hi Jim,
Would it be possible, that you take a look at my questions form the previous email?
Thanks in advance, Marcin
śr., 1 sie 2018 o 17:11 Marcin Wojtas mw@semihalf.com napisał(a):
Hi Jim,
wt., 31 lip 2018 o 18:09 Jim Perrin jperrin@centos.org napisał(a):
On 07/30/2018 07:00 AM, Marcin Wojtas wrote:
Hi Jim,
It's been a while, since I sent the patch. Any objections about merging?
Is v4.11 kernel still a valid baseline or for the next releases or we should use v4.14? When is that transition and next release supposed to happen?
The current version of the supported kernel is 4.14, so this would need to be updated to support the 4.14 tree.
There is still a gap between vanilla v4.14 version of the driver and the upstream commits that allow to use it with ACPI (although much smaller than for v4.11). What is a procedure of providing you the patches?
Best regards, Marcinsob., 23 cze 2018 o 08:18 Marcin Wojtas mw@semihalf.com napisał(a):
Hi,
I'm sending a patch that is applicable on top of the kernel sig-altarch7-aarch64 branch. It enables ACPI support for the Marvell Armada7k8k NIC - this required backporting very big amount of patches (all merged upstream), hence I decided to attach the single commit, instead of issueing 'git send-email' of it.
Once we got to 4.14, there didn't seem to be a demand for the sig-altarch kernel to continue so I left it at the previous version. From the sounds of things, you still need it for this to work?
Is v4.14-based Centos an official version to support aarch64? If yes, I'd complement this version with the needed patches.
Btw. if I google 'Centos aarch64' the links point to the altarch/7 images. What is their kernel base then? In other words, where should one search for most recent image of aarch64 images? Is there any public release schedule available?
About sig-altarch tree, I'd need to make sure internally. From your perspective, would it be recommended?
Despite many attempts I wasn't able to build entire rpm package with the mock build utility, however I managed to test the clean kernel v4.11 with applied all patches and built with updated .config. Please let know if this patch is sufficient and can be merged.
I'm guessing no unless it patches/builds against 4.14 as well. I'll see about updating the sig-altarch tree so that we can test there.
For sure I need to send updated patch list for v4.14. Please see my question above.
Thanks, Marcin
On 09/03/2018 09:24 AM, Marcin Wojtas wrote:
Hi Jim,
I've prepared list of mainline patches, that smoothely apply onto v4.14 baseline. The NIC is working with ACPI as expected. Because it's not clear to me, how patches should be submitted (please see my questions from previous emails), below you can find a full list.
Please let know, how can we proceed from here and how possibly could I test real Centos image with patches applied.
Thanks, Marcin
====== LIST of MVPP2 Patches ====== 38c5eb93aca9 net: mvpp2: remove useless goto (v4.15-rc1) 2d1d7df8a365 net: mvpp2: set the Rx FIFO size depending on the port speeds for PPv2.2 (v4.15-rc1) 7c10f9742d76 net: mvpp2: initialize the Tx FIFO size (v4.15-rc1) 1d7d15d79fb4 net: mvpp2: initialize the RSS tables (v4.15-rc1) 1d17db08c056 net: mvpp2: limit TSO segments and use stop/wake thresholds (v4.15-rc1) 02856a3ba633 net: mvpp2: use the aggr txq size define everywhere (v4.15-rc1) 6eb5d375cefc net: mvpp2: simplify the Tx desc set DMA logic (v4.15-rc1) 118d6298f6f0 net: mvpp2: add ethtool GOP statistics (v4.15-rc1) e5c500eb298a net: mvpp2: fix GOP statistics loop start and stop conditions (v4.15-rc1) ba2d8d887d96 net: mvpp2: fix the txq_init error path (v4.15-rc2) 26146b0e6b68 net: mvpp2: cleanup probed ports in the probe error path (v4.15-rc2) e749aca84b10 net: mvpp2: do not disable GMAC padding (v4.15-rc2) 76e583c5f50e net: mvpp2: check ethtool sets the Tx ring size is to a valid min value (v4.15-rc2) a154f8e399a0 net: mvpp2: allocate zeroed tx descriptors (v4.15-rc3) 8a7b741e76cd net: mvpp2: fix the RSS table entry offset (v4.15-rc3) b70d4a5195c7 net: mvpp2: only free the TSO header buffers when it was allocated (v4.16-rc1) 7cf87e4a5c2b net: mvpp2: split the max ring size from the default one (v4.16-rc1) 385c284fee84 net: mvpp2: align values in ethtool get_coalesce (v4.16-rc1) 24b28ccb8575 net: mvpp2: report the tx-usec coalescing information to ethtool (v4.16-rc1) 86162281c25f net: mvpp2: adjust the coalescing parameters (v4.16-rc1) babe2dbb28e7 device property: Introduce fwnode_get_mac_address() (v4.16-rc1) b28f263b8670 device property: Introduce fwnode_get_phy_mode() (v4.16-rc1) 7c6c57f2ab2c device property: Introduce fwnode_irq_get() (v4.16-rc1) 3395de96ae59 device property: Allow iterating over available child fwnodes (v4.16-rc1) bf147153d7f4 net: mvpp2: simplify maintaining enabled ports' list (v4.16-rc1) 248122212f68 net: mvpp2: use device_*/fwnode_* APIs instead of of_* (v4.16-rc1) a75edc7c2eab net: mvpp2: enable ACPI support in the driver (v4.16-rc1) 7ac8ff95f48c mvpp2: fix multicast address filter (v4.16-rc3) 56beda3db602 net: mvpp2: Add hardware offloading for VLAN filtering (v4.17-rc1) 01d049366529 net: mvpp2: use the same buffer pool for all ports (v4.17-rc1) effbf5f58d64 net: mvpp2: update the BM buffer free/destroy logic (v4.17-rc1) 93ff130f1c2b net: mvpp2: use a data size of 10kB for Tx FIFO on port 0 (v4.17-rc1) 381c56712db4 net: mvpp2: enable UDP/TCP checksum over IPv6 (v4.17-rc1) 576193f2d579 net: mvpp2: jumbo frames support (v4.17-rc1) 6e61e10a8a96 net: mvpp2: mvpp2_check_hw_buf_num() can be static (v4.17-rc1) ce2a27c761ac net: mvpp2: Simplify MAC filtering function parameters (v4.17-rc1) 10fea26ce2aa net: mvpp2: Add support for unicast filtering (v4.17-rc1) e2e031640b3a net: mvpp2: use correct index on array mvpp2_pools (v4.17-rc1) 47e0e14eb1a6 net: mvpp2: Make mvpp2_prs_hw_read a parser entry init function (v4.17-rc1) 0c6d9b44145d net: mvpp2: Don't use dynamic allocs for local variables (v4.17-rc1) cdcfeb0fb473 net: mvpp2: Use relaxed I/O in data path (v4.17-rc1) 3d92f0b58206 net: mvpp2: Fix parser entry init boundary check (v4.17-rc1) 982e05001c47 net: mvpp2: Fix TCAM filter reserved range (v4.17-rc2) da42bb271305 net: mvpp2: Fix DMA address mask size (v4.17-rc2) 45f972adb7f4 net: mvpp2: Fix clk error path in mvpp2_probe (v4.17-rc4) 9af771ced473 net: mvpp2: Fix clock resource by adding missing mg_core_clk (v4.17-rc4) ====== END OF LIST =============
pon., 13 sie 2018 o 10:50 Marcin Wojtas mw@semihalf.com napisał(a):
Hi Jim,
Would it be possible, that you take a look at my questions form the previous email?
Thanks in advance, Marcin
śr., 1 sie 2018 o 17:11 Marcin Wojtas mw@semihalf.com napisał(a):
Hi Jim,
wt., 31 lip 2018 o 18:09 Jim Perrin jperrin@centos.org napisał(a):
On 07/30/2018 07:00 AM, Marcin Wojtas wrote:
Hi Jim,
It's been a while, since I sent the patch. Any objections about merging?
Is v4.11 kernel still a valid baseline or for the next releases or we should use v4.14? When is that transition and next release supposed to happen?
The current version of the supported kernel is 4.14, so this would need to be updated to support the 4.14 tree.
There is still a gap between vanilla v4.14 version of the driver and the upstream commits that allow to use it with ACPI (although much smaller than for v4.11). What is a procedure of providing you the patches?
Best regards, Marcinsob., 23 cze 2018 o 08:18 Marcin Wojtas mw@semihalf.com napisał(a):
Hi,
I'm sending a patch that is applicable on top of the kernel sig-altarch7-aarch64 branch. It enables ACPI support for the Marvell Armada7k8k NIC - this required backporting very big amount of patches (all merged upstream), hence I decided to attach the single commit, instead of issueing 'git send-email' of it.
Once we got to 4.14, there didn't seem to be a demand for the sig-altarch kernel to continue so I left it at the previous version. From the sounds of things, you still need it for this to work?
Is v4.14-based Centos an official version to support aarch64? If yes, I'd complement this version with the needed patches.
Btw. if I google 'Centos aarch64' the links point to the altarch/7 images. What is their kernel base then? In other words, where should one search for most recent image of aarch64 images? Is there any public release schedule available?
About sig-altarch tree, I'd need to make sure internally. From your perspective, would it be recommended?
Despite many attempts I wasn't able to build entire rpm package with the mock build utility, however I managed to test the clean kernel v4.11 with applied all patches and built with updated .config. Please let know if this patch is sufficient and can be merged.
I'm guessing no unless it patches/builds against 4.14 as well. I'll see about updating the sig-altarch tree so that we can test there.
For sure I need to send updated patch list for v4.14. Please see my question above.
Thanks, Marcin
You can send me the individual patches directly. Make sure they apply against the latest kernel-alt:
https://git.centos.org/summary/rpms!kernel-alt.git
Thanks, Johnny Hughes
Hi Johnny,
I attach all patches, they will easily apply (git am centos_mvpp2/*) onto v4.14.0 baseline. Also a kernel-alt-4.14.0-aarch64.config file must be updated with following additions: +CONFIG_ARCH_MVEBU=y +CONFIG_MVPP2=m +CONFIG_MARVELL_10G_PHY=m
For reference I attach the config file as well (I took kernel-alt-4.14.0-aarch64.config from top of c7-alt branch to v4.14.0 baseline, enabled 3 configs as above and saved).
Please let know if you need any help. About testing, what would be the easiest way to try full centos image with the kernel? Install the latest available iso from: http://mirror.centos.org/altarch/7/isos/aarch64/ and run kernel update? Or a different way is recommended?
Thanks, Marcin
wt., 4 wrz 2018 o 15:00 Johnny Hughes johnny@centos.org napisał(a):
On 09/03/2018 09:24 AM, Marcin Wojtas wrote:
Hi Jim,
I've prepared list of mainline patches, that smoothely apply onto v4.14 baseline. The NIC is working with ACPI as expected. Because it's not clear to me, how patches should be submitted (please see my questions from previous emails), below you can find a full list.
Please let know, how can we proceed from here and how possibly could I test real Centos image with patches applied.
Thanks, Marcin
====== LIST of MVPP2 Patches ====== 38c5eb93aca9 net: mvpp2: remove useless goto (v4.15-rc1) 2d1d7df8a365 net: mvpp2: set the Rx FIFO size depending on the port speeds for PPv2.2 (v4.15-rc1) 7c10f9742d76 net: mvpp2: initialize the Tx FIFO size (v4.15-rc1) 1d7d15d79fb4 net: mvpp2: initialize the RSS tables (v4.15-rc1) 1d17db08c056 net: mvpp2: limit TSO segments and use stop/wake thresholds (v4.15-rc1) 02856a3ba633 net: mvpp2: use the aggr txq size define everywhere (v4.15-rc1) 6eb5d375cefc net: mvpp2: simplify the Tx desc set DMA logic (v4.15-rc1) 118d6298f6f0 net: mvpp2: add ethtool GOP statistics (v4.15-rc1) e5c500eb298a net: mvpp2: fix GOP statistics loop start and stop conditions (v4.15-rc1) ba2d8d887d96 net: mvpp2: fix the txq_init error path (v4.15-rc2) 26146b0e6b68 net: mvpp2: cleanup probed ports in the probe error path (v4.15-rc2) e749aca84b10 net: mvpp2: do not disable GMAC padding (v4.15-rc2) 76e583c5f50e net: mvpp2: check ethtool sets the Tx ring size is to a valid min value (v4.15-rc2) a154f8e399a0 net: mvpp2: allocate zeroed tx descriptors (v4.15-rc3) 8a7b741e76cd net: mvpp2: fix the RSS table entry offset (v4.15-rc3) b70d4a5195c7 net: mvpp2: only free the TSO header buffers when it was allocated (v4.16-rc1) 7cf87e4a5c2b net: mvpp2: split the max ring size from the default one (v4.16-rc1) 385c284fee84 net: mvpp2: align values in ethtool get_coalesce (v4.16-rc1) 24b28ccb8575 net: mvpp2: report the tx-usec coalescing information to ethtool (v4.16-rc1) 86162281c25f net: mvpp2: adjust the coalescing parameters (v4.16-rc1) babe2dbb28e7 device property: Introduce fwnode_get_mac_address() (v4.16-rc1) b28f263b8670 device property: Introduce fwnode_get_phy_mode() (v4.16-rc1) 7c6c57f2ab2c device property: Introduce fwnode_irq_get() (v4.16-rc1) 3395de96ae59 device property: Allow iterating over available child fwnodes (v4.16-rc1) bf147153d7f4 net: mvpp2: simplify maintaining enabled ports' list (v4.16-rc1) 248122212f68 net: mvpp2: use device_*/fwnode_* APIs instead of of_* (v4.16-rc1) a75edc7c2eab net: mvpp2: enable ACPI support in the driver (v4.16-rc1) 7ac8ff95f48c mvpp2: fix multicast address filter (v4.16-rc3) 56beda3db602 net: mvpp2: Add hardware offloading for VLAN filtering (v4.17-rc1) 01d049366529 net: mvpp2: use the same buffer pool for all ports (v4.17-rc1) effbf5f58d64 net: mvpp2: update the BM buffer free/destroy logic (v4.17-rc1) 93ff130f1c2b net: mvpp2: use a data size of 10kB for Tx FIFO on port 0 (v4.17-rc1) 381c56712db4 net: mvpp2: enable UDP/TCP checksum over IPv6 (v4.17-rc1) 576193f2d579 net: mvpp2: jumbo frames support (v4.17-rc1) 6e61e10a8a96 net: mvpp2: mvpp2_check_hw_buf_num() can be static (v4.17-rc1) ce2a27c761ac net: mvpp2: Simplify MAC filtering function parameters (v4.17-rc1) 10fea26ce2aa net: mvpp2: Add support for unicast filtering (v4.17-rc1) e2e031640b3a net: mvpp2: use correct index on array mvpp2_pools (v4.17-rc1) 47e0e14eb1a6 net: mvpp2: Make mvpp2_prs_hw_read a parser entry init function (v4.17-rc1) 0c6d9b44145d net: mvpp2: Don't use dynamic allocs for local variables (v4.17-rc1) cdcfeb0fb473 net: mvpp2: Use relaxed I/O in data path (v4.17-rc1) 3d92f0b58206 net: mvpp2: Fix parser entry init boundary check (v4.17-rc1) 982e05001c47 net: mvpp2: Fix TCAM filter reserved range (v4.17-rc2) da42bb271305 net: mvpp2: Fix DMA address mask size (v4.17-rc2) 45f972adb7f4 net: mvpp2: Fix clk error path in mvpp2_probe (v4.17-rc4) 9af771ced473 net: mvpp2: Fix clock resource by adding missing mg_core_clk (v4.17-rc4) ====== END OF LIST =============
pon., 13 sie 2018 o 10:50 Marcin Wojtas mw@semihalf.com napisał(a):
Hi Jim,
Would it be possible, that you take a look at my questions form the previous email?
Thanks in advance, Marcin
śr., 1 sie 2018 o 17:11 Marcin Wojtas mw@semihalf.com napisał(a):
Hi Jim,
wt., 31 lip 2018 o 18:09 Jim Perrin jperrin@centos.org napisał(a):
On 07/30/2018 07:00 AM, Marcin Wojtas wrote:
Hi Jim,
It's been a while, since I sent the patch. Any objections about merging?
Is v4.11 kernel still a valid baseline or for the next releases or we should use v4.14? When is that transition and next release supposed to happen?
The current version of the supported kernel is 4.14, so this would need to be updated to support the 4.14 tree.
There is still a gap between vanilla v4.14 version of the driver and the upstream commits that allow to use it with ACPI (although much smaller than for v4.11). What is a procedure of providing you the patches?
Best regards, Marcinsob., 23 cze 2018 o 08:18 Marcin Wojtas mw@semihalf.com napisał(a): > > Hi, > > I'm sending a patch that is applicable on top of the kernel > sig-altarch7-aarch64 branch. It enables ACPI support for the Marvell > Armada7k8k NIC - this required backporting very big amount of patches > (all merged upstream), hence I decided to attach the single commit, > instead of issueing 'git send-email' of it. >
Once we got to 4.14, there didn't seem to be a demand for the sig-altarch kernel to continue so I left it at the previous version. From the sounds of things, you still need it for this to work?
Is v4.14-based Centos an official version to support aarch64? If yes, I'd complement this version with the needed patches.
Btw. if I google 'Centos aarch64' the links point to the altarch/7 images. What is their kernel base then? In other words, where should one search for most recent image of aarch64 images? Is there any public release schedule available?
About sig-altarch tree, I'd need to make sure internally. From your perspective, would it be recommended?
> Despite many attempts I wasn't able to build entire rpm package with > the mock build utility, however I managed to test the clean kernel > v4.11 with applied all patches and built with updated .config. Please > let know if this patch is sufficient and can be merged.
I'm guessing no unless it patches/builds against 4.14 as well. I'll see about updating the sig-altarch tree so that we can test there.
For sure I need to send updated patch list for v4.14. Please see my question above.
Thanks, Marcin
You can send me the individual patches directly. Make sure they apply against the latest kernel-alt:
https://git.centos.org/summary/rpms!kernel-alt.git
Thanks, Johnny Hughes
Hi Johny,
Were you able to take a look at the patches?
Best regards, Marcin
wt., 4 wrz 2018 o 18:22 Marcin Wojtas mw@semihalf.com napisał(a):
Hi Johnny,
I attach all patches, they will easily apply (git am centos_mvpp2/*) onto v4.14.0 baseline. Also a kernel-alt-4.14.0-aarch64.config file must be updated with following additions: +CONFIG_ARCH_MVEBU=y +CONFIG_MVPP2=m +CONFIG_MARVELL_10G_PHY=m
For reference I attach the config file as well (I took kernel-alt-4.14.0-aarch64.config from top of c7-alt branch to v4.14.0 baseline, enabled 3 configs as above and saved).
Please let know if you need any help. About testing, what would be the easiest way to try full centos image with the kernel? Install the latest available iso from: http://mirror.centos.org/altarch/7/isos/aarch64/ and run kernel update? Or a different way is recommended?
Thanks, Marcin
wt., 4 wrz 2018 o 15:00 Johnny Hughes johnny@centos.org napisał(a):
On 09/03/2018 09:24 AM, Marcin Wojtas wrote:
Hi Jim,
I've prepared list of mainline patches, that smoothely apply onto v4.14 baseline. The NIC is working with ACPI as expected. Because it's not clear to me, how patches should be submitted (please see my questions from previous emails), below you can find a full list.
Please let know, how can we proceed from here and how possibly could I test real Centos image with patches applied.
Thanks, Marcin
====== LIST of MVPP2 Patches ====== 38c5eb93aca9 net: mvpp2: remove useless goto (v4.15-rc1) 2d1d7df8a365 net: mvpp2: set the Rx FIFO size depending on the port
speeds for
PPv2.2 (v4.15-rc1) 7c10f9742d76 net: mvpp2: initialize the Tx FIFO size (v4.15-rc1) 1d7d15d79fb4 net: mvpp2: initialize the RSS tables (v4.15-rc1) 1d17db08c056 net: mvpp2: limit TSO segments and use stop/wake
thresholds
(v4.15-rc1) 02856a3ba633 net: mvpp2: use the aggr txq size define everywhere
(v4.15-rc1)
6eb5d375cefc net: mvpp2: simplify the Tx desc set DMA logic (v4.15-rc1) 118d6298f6f0 net: mvpp2: add ethtool GOP statistics (v4.15-rc1) e5c500eb298a net: mvpp2: fix GOP statistics loop start and stop
conditions
(v4.15-rc1) ba2d8d887d96 net: mvpp2: fix the txq_init error path (v4.15-rc2) 26146b0e6b68 net: mvpp2: cleanup probed ports in the probe error path (v4.15-rc2) e749aca84b10 net: mvpp2: do not disable GMAC padding (v4.15-rc2) 76e583c5f50e net: mvpp2: check ethtool sets the Tx ring size is to a
valid min
value (v4.15-rc2) a154f8e399a0 net: mvpp2: allocate zeroed tx descriptors (v4.15-rc3) 8a7b741e76cd net: mvpp2: fix the RSS table entry offset (v4.15-rc3) b70d4a5195c7 net: mvpp2: only free the TSO header buffers when it was
allocated
(v4.16-rc1) 7cf87e4a5c2b net: mvpp2: split the max ring size from the default one (v4.16-rc1) 385c284fee84 net: mvpp2: align values in ethtool get_coalesce
(v4.16-rc1)
24b28ccb8575 net: mvpp2: report the tx-usec coalescing information to
ethtool
(v4.16-rc1) 86162281c25f net: mvpp2: adjust the coalescing parameters (v4.16-rc1) babe2dbb28e7 device property: Introduce fwnode_get_mac_address()
(v4.16-rc1)
b28f263b8670 device property: Introduce fwnode_get_phy_mode()
(v4.16-rc1)
7c6c57f2ab2c device property: Introduce fwnode_irq_get() (v4.16-rc1) 3395de96ae59 device property: Allow iterating over available child
fwnodes
(v4.16-rc1) bf147153d7f4 net: mvpp2: simplify maintaining enabled ports' list
(v4.16-rc1)
248122212f68 net: mvpp2: use device_*/fwnode_* APIs instead of of_*
(v4.16-rc1)
a75edc7c2eab net: mvpp2: enable ACPI support in the driver (v4.16-rc1) 7ac8ff95f48c mvpp2: fix multicast address filter (v4.16-rc3) 56beda3db602 net: mvpp2: Add hardware offloading for VLAN filtering
(v4.17-rc1)
01d049366529 net: mvpp2: use the same buffer pool for all ports
(v4.17-rc1)
effbf5f58d64 net: mvpp2: update the BM buffer free/destroy logic
(v4.17-rc1)
93ff130f1c2b net: mvpp2: use a data size of 10kB for Tx FIFO on port 0 (v4.17-rc1) 381c56712db4 net: mvpp2: enable UDP/TCP checksum over IPv6 (v4.17-rc1) 576193f2d579 net: mvpp2: jumbo frames support (v4.17-rc1) 6e61e10a8a96 net: mvpp2: mvpp2_check_hw_buf_num() can be static
(v4.17-rc1)
ce2a27c761ac net: mvpp2: Simplify MAC filtering function parameters
(v4.17-rc1)
10fea26ce2aa net: mvpp2: Add support for unicast filtering (v4.17-rc1) e2e031640b3a net: mvpp2: use correct index on array mvpp2_pools
(v4.17-rc1)
47e0e14eb1a6 net: mvpp2: Make mvpp2_prs_hw_read a parser entry init
function
(v4.17-rc1) 0c6d9b44145d net: mvpp2: Don't use dynamic allocs for local variables (v4.17-rc1) cdcfeb0fb473 net: mvpp2: Use relaxed I/O in data path (v4.17-rc1) 3d92f0b58206 net: mvpp2: Fix parser entry init boundary check
(v4.17-rc1)
982e05001c47 net: mvpp2: Fix TCAM filter reserved range (v4.17-rc2) da42bb271305 net: mvpp2: Fix DMA address mask size (v4.17-rc2) 45f972adb7f4 net: mvpp2: Fix clk error path in mvpp2_probe (v4.17-rc4) 9af771ced473 net: mvpp2: Fix clock resource by adding missing
mg_core_clk
(v4.17-rc4) ====== END OF LIST =============
pon., 13 sie 2018 o 10:50 Marcin Wojtas mw@semihalf.com napisał(a):
Hi Jim,
Would it be possible, that you take a look at my questions form the previous email?
Thanks in advance, Marcin
śr., 1 sie 2018 o 17:11 Marcin Wojtas mw@semihalf.com napisał(a):
Hi Jim,
wt., 31 lip 2018 o 18:09 Jim Perrin jperrin@centos.org napisał(a):
On 07/30/2018 07:00 AM, Marcin Wojtas wrote: > Hi Jim, > > It's been a while, since I sent the patch. Any objections about
merging?
> > Is v4.11 kernel still a valid baseline or for the next releases or
we
> should use v4.14? When is that transition and next release
supposed to
> happen? >
The current version of the supported kernel is 4.14, so this would
need
to be updated to support the 4.14 tree.
There is still a gap between vanilla v4.14 version of the driver and the upstream commits that allow to use it with ACPI (although much smaller than for v4.11). What is a procedure of providing you the patches?
> Best regards, > Marcinsob., 23 cze 2018 o 08:18 Marcin Wojtas mw@semihalf.com
napisał(a):
>> >> Hi, >> >> I'm sending a patch that is applicable on top of the kernel >> sig-altarch7-aarch64 branch. It enables ACPI support for the
Marvell
>> Armada7k8k NIC - this required backporting very big amount of
patches
>> (all merged upstream), hence I decided to attach the single
commit,
>> instead of issueing 'git send-email' of it. >>
Once we got to 4.14, there didn't seem to be a demand for the sig-altarch kernel to continue so I left it at the previous version. From the sounds of things, you still need it for this to work?
Is v4.14-based Centos an official version to support aarch64? If yes, I'd complement this version with the needed patches.
Btw. if I google 'Centos aarch64' the links point to the altarch/7 images. What is their kernel base then? In other words, where should one search for most recent image of aarch64 images? Is there any public release schedule available?
About sig-altarch tree, I'd need to make sure internally. From your perspective, would it be recommended?
>> Despite many attempts I wasn't able to build entire rpm package
with
>> the mock build utility, however I managed to test the clean kernel >> v4.11 with applied all patches and built with updated .config.
Please
>> let know if this patch is sufficient and can be merged.
I'm guessing no unless it patches/builds against 4.14 as well. I'll
see
about updating the sig-altarch tree so that we can test there.
For sure I need to send updated patch list for v4.14. Please see my question above.
Thanks, Marcin
You can send me the individual patches directly. Make sure they apply against the latest kernel-alt:
https://git.centos.org/summary/rpms!kernel-alt.git
Thanks, Johnny Hughes
Marcin,
I have added these patches to the new kernel that I am going to release later today.
There seemed to be some new config entries (other than just the 3 you specified). I think I enabled everything and created modules for them for aarch64.
Please take a look at the new kernel and make sure the config is like you want it.
kernel-alt-4.14.0-49.13.1.el7a.src.rpm on target c7.1804.u.aarch64
(It should be signed and released in a couple hours, I am still going to do a boot test on a real machine .. I already booted it in a VM)
Thanks, Johnny Hughes
On 09/11/2018 08:34 AM, Marcin Wojtas wrote:
Hi Johny,
Were you able to take a look at the patches?
Best regards, Marcin
wt., 4 wrz 2018 o 18:22 Marcin Wojtas <mw@semihalf.com mailto:mw@semihalf.com> napisał(a):
Hi Johnny, I attach all patches, they will easily apply (git am centos_mvpp2/*) onto v4.14.0 baseline. Also a kernel-alt-4.14.0-aarch64.config file must be updated with following additions: +CONFIG_ARCH_MVEBU=y +CONFIG_MVPP2=m +CONFIG_MARVELL_10G_PHY=m For reference I attach the config file as well (I took kernel-alt-4.14.0-aarch64.config from top of c7-alt branch to v4.14.0 baseline, enabled 3 configs as above and saved). Please let know if you need any help. About testing, what would be the easiest way to try full centos image with the kernel? Install the latest available iso from: http://mirror.centos.org/altarch/7/isos/aarch64/ and run kernel update? Or a different way is recommended? Thanks, Marcin wt., 4 wrz 2018 o 15:00 Johnny Hughes <johnny@centos.org <mailto:johnny@centos.org>> napisał(a): > > On 09/03/2018 09:24 AM, Marcin Wojtas wrote: > > Hi Jim, > > > > I've prepared list of mainline patches, that smoothely apply onto > > v4.14 baseline. The NIC is working with ACPI as expected. > > Because it's not clear to me, how patches should be submitted (please > > see my questions from previous emails), below you can find a full > > list. > > > > Please let know, how can we proceed from here and how possibly could I > > test real Centos image with patches applied. > > > > Thanks, > > Marcin > > > > ====== LIST of MVPP2 Patches ====== > > 38c5eb93aca9 net: mvpp2: remove useless goto (v4.15-rc1) > > 2d1d7df8a365 net: mvpp2: set the Rx FIFO size depending on the port speeds for > > PPv2.2 (v4.15-rc1) > > 7c10f9742d76 net: mvpp2: initialize the Tx FIFO size (v4.15-rc1) > > 1d7d15d79fb4 net: mvpp2: initialize the RSS tables (v4.15-rc1) > > 1d17db08c056 net: mvpp2: limit TSO segments and use stop/wake thresholds > > (v4.15-rc1) > > 02856a3ba633 net: mvpp2: use the aggr txq size define everywhere (v4.15-rc1) > > 6eb5d375cefc net: mvpp2: simplify the Tx desc set DMA logic (v4.15-rc1) > > 118d6298f6f0 net: mvpp2: add ethtool GOP statistics (v4.15-rc1) > > e5c500eb298a net: mvpp2: fix GOP statistics loop start and stop conditions > > (v4.15-rc1) > > ba2d8d887d96 net: mvpp2: fix the txq_init error path (v4.15-rc2) > > 26146b0e6b68 net: mvpp2: cleanup probed ports in the probe error path > > (v4.15-rc2) > > e749aca84b10 net: mvpp2: do not disable GMAC padding (v4.15-rc2) > > 76e583c5f50e net: mvpp2: check ethtool sets the Tx ring size is to a valid min > > value (v4.15-rc2) > > a154f8e399a0 net: mvpp2: allocate zeroed tx descriptors (v4.15-rc3) > > 8a7b741e76cd net: mvpp2: fix the RSS table entry offset (v4.15-rc3) > > b70d4a5195c7 net: mvpp2: only free the TSO header buffers when it was allocated > > (v4.16-rc1) > > 7cf87e4a5c2b net: mvpp2: split the max ring size from the default one > > (v4.16-rc1) > > 385c284fee84 net: mvpp2: align values in ethtool get_coalesce (v4.16-rc1) > > 24b28ccb8575 net: mvpp2: report the tx-usec coalescing information to ethtool > > (v4.16-rc1) > > 86162281c25f net: mvpp2: adjust the coalescing parameters (v4.16-rc1) > > babe2dbb28e7 device property: Introduce fwnode_get_mac_address() (v4.16-rc1) > > b28f263b8670 device property: Introduce fwnode_get_phy_mode() (v4.16-rc1) > > 7c6c57f2ab2c device property: Introduce fwnode_irq_get() (v4.16-rc1) > > 3395de96ae59 device property: Allow iterating over available child fwnodes > > (v4.16-rc1) > > bf147153d7f4 net: mvpp2: simplify maintaining enabled ports' list (v4.16-rc1) > > 248122212f68 net: mvpp2: use device_*/fwnode_* APIs instead of of_* (v4.16-rc1) > > a75edc7c2eab net: mvpp2: enable ACPI support in the driver (v4.16-rc1) > > 7ac8ff95f48c mvpp2: fix multicast address filter (v4.16-rc3) > > 56beda3db602 net: mvpp2: Add hardware offloading for VLAN filtering (v4.17-rc1) > > 01d049366529 net: mvpp2: use the same buffer pool for all ports (v4.17-rc1) > > effbf5f58d64 net: mvpp2: update the BM buffer free/destroy logic (v4.17-rc1) > > 93ff130f1c2b net: mvpp2: use a data size of 10kB for Tx FIFO on port 0 > > (v4.17-rc1) > > 381c56712db4 net: mvpp2: enable UDP/TCP checksum over IPv6 (v4.17-rc1) > > 576193f2d579 net: mvpp2: jumbo frames support (v4.17-rc1) > > 6e61e10a8a96 net: mvpp2: mvpp2_check_hw_buf_num() can be static (v4.17-rc1) > > ce2a27c761ac net: mvpp2: Simplify MAC filtering function parameters (v4.17-rc1) > > 10fea26ce2aa net: mvpp2: Add support for unicast filtering (v4.17-rc1) > > e2e031640b3a net: mvpp2: use correct index on array mvpp2_pools (v4.17-rc1) > > 47e0e14eb1a6 net: mvpp2: Make mvpp2_prs_hw_read a parser entry init function > > (v4.17-rc1) > > 0c6d9b44145d net: mvpp2: Don't use dynamic allocs for local variables > > (v4.17-rc1) > > cdcfeb0fb473 net: mvpp2: Use relaxed I/O in data path (v4.17-rc1) > > 3d92f0b58206 net: mvpp2: Fix parser entry init boundary check (v4.17-rc1) > > 982e05001c47 net: mvpp2: Fix TCAM filter reserved range (v4.17-rc2) > > da42bb271305 net: mvpp2: Fix DMA address mask size (v4.17-rc2) > > 45f972adb7f4 net: mvpp2: Fix clk error path in mvpp2_probe (v4.17-rc4) > > 9af771ced473 net: mvpp2: Fix clock resource by adding missing mg_core_clk > > (v4.17-rc4) > > ====== END OF LIST ============= > > > > > > pon., 13 sie 2018 o 10:50 Marcin Wojtas <mw@semihalf.com <mailto:mw@semihalf.com>> napisał(a): > >> > >> Hi Jim, > >> > >> Would it be possible, that you take a look at my questions form the > >> previous email? > >> > >> Thanks in advance, > >> Marcin > >> > >> śr., 1 sie 2018 o 17:11 Marcin Wojtas <mw@semihalf.com <mailto:mw@semihalf.com>> napisał(a): > >>> > >>> Hi Jim, > >>> > >>> wt., 31 lip 2018 o 18:09 Jim Perrin <jperrin@centos.org <mailto:jperrin@centos.org>> napisał(a): > >>>> > >>>> > >>>> > >>>> On 07/30/2018 07:00 AM, Marcin Wojtas wrote: > >>>>> Hi Jim, > >>>>> > >>>>> It's been a while, since I sent the patch. Any objections about merging? > >>>>> > >>>>> Is v4.11 kernel still a valid baseline or for the next releases or we > >>>>> should use v4.14? When is that transition and next release supposed to > >>>>> happen? > >>>>> > >>>> > >>>> The current version of the supported kernel is 4.14, so this would need > >>>> to be updated to support the 4.14 tree. > >>>> > >>> > >>> There is still a gap between vanilla v4.14 version of the driver and > >>> the upstream commits that allow to use it with ACPI (although much > >>> smaller than for v4.11). What is a procedure of providing you the > >>> patches? > >>> > >>>> > >>>> > >>>>> Best regards, > >>>>> Marcinsob., 23 cze 2018 o 08:18 Marcin Wojtas <mw@semihalf.com <mailto:mw@semihalf.com>> napisał(a): > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I'm sending a patch that is applicable on top of the kernel > >>>>>> sig-altarch7-aarch64 branch. It enables ACPI support for the Marvell > >>>>>> Armada7k8k NIC - this required backporting very big amount of patches > >>>>>> (all merged upstream), hence I decided to attach the single commit, > >>>>>> instead of issueing 'git send-email' of it. > >>>>>> > >>>> > >>>> > >>>> Once we got to 4.14, there didn't seem to be a demand for the > >>>> sig-altarch kernel to continue so I left it at the previous version. > >>>> From the sounds of things, you still need it for this to work? > >>> > >>> Is v4.14-based Centos an official version to support aarch64? If yes, > >>> I'd complement this version with the needed patches. > >>> > >>> Btw. if I google 'Centos aarch64' the links point to the altarch/7 > >>> images. What is their kernel base then? In other words, where should > >>> one search > >>> for most recent image of aarch64 images? Is there any public release > >>> schedule available? > >>> > >>> About sig-altarch tree, I'd need to make sure internally. From your > >>> perspective, would it be recommended? > >>> > >>>> > >>>>>> Despite many attempts I wasn't able to build entire rpm package with > >>>>>> the mock build utility, however I managed to test the clean kernel > >>>>>> v4.11 with applied all patches and built with updated .config. Please > >>>>>> let know if this patch is sufficient and can be merged. > >>>> > >>>> I'm guessing no unless it patches/builds against 4.14 as well. I'll see > >>>> about updating the sig-altarch tree so that we can test there. > >>>> > >>> > >>> For sure I need to send updated patch list for v4.14. Please see my > >>> question above. > >>> > >>> Thanks, > >>> Marcin > > > You can send me the individual patches directly. Make sure they apply > against the latest kernel-alt: > > https://git.centos.org/summary/rpms!kernel-alt.git <https://git.centos.org/summary/rpms%21kernel-alt.git> > > Thanks, > Johnny Hughes >
Hi Johnny,
Thank you for the information.
pt., 28 wrz 2018 o 13:02 Johnny Hughes johnny@centos.org napisał(a):
Marcin,
I have added these patches to the new kernel that I am going to release later today.
There seemed to be some new config entries (other than just the 3 you specified). I think I enabled everything and created modules for them for aarch64.
Please take a look at the new kernel and make sure the config is like you want it.
kernel-alt-4.14.0-49.13.1.el7a.src.rpm on target c7.1804.u.aarch64
I checked the config in the build.log and everything seems in place.
(It should be signed and released in a couple hours, I am still going to do a boot test on a real machine .. I already booted it in a VM)
What will be the easiest way to test it? Do you publish some kind of daily build isos, that one can burn and install?
Best regards, Marcin
Thanks, Johnny Hughes
On 09/11/2018 08:34 AM, Marcin Wojtas wrote:
Hi Johny,
Were you able to take a look at the patches?
Best regards, Marcin
wt., 4 wrz 2018 o 18:22 Marcin Wojtas <mw@semihalf.com mailto:mw@semihalf.com> napisał(a):
Hi Johnny, I attach all patches, they will easily apply (git am centos_mvpp2/*) onto v4.14.0 baseline. Also a kernel-alt-4.14.0-aarch64.config file must be updated with following additions: +CONFIG_ARCH_MVEBU=y +CONFIG_MVPP2=m +CONFIG_MARVELL_10G_PHY=m For reference I attach the config file as well (I took kernel-alt-4.14.0-aarch64.config from top of c7-alt branch to v4.14.0 baseline, enabled 3 configs as above and saved). Please let know if you need any help. About testing, what would be the easiest way to try full centos image with the kernel? Install the latest available iso from: http://mirror.centos.org/altarch/7/isos/aarch64/ and run kernel update? Or a different way is recommended? Thanks, Marcin wt., 4 wrz 2018 o 15:00 Johnny Hughes <johnny@centos.org <mailto:johnny@centos.org>> napisał(a): > > On 09/03/2018 09:24 AM, Marcin Wojtas wrote: > > Hi Jim, > > > > I've prepared list of mainline patches, that smoothely apply onto > > v4.14 baseline. The NIC is working with ACPI as expected. > > Because it's not clear to me, how patches should be submitted (please > > see my questions from previous emails), below you can find a full > > list. > > > > Please let know, how can we proceed from here and how possibly could I > > test real Centos image with patches applied. > > > > Thanks, > > Marcin > > > > ====== LIST of MVPP2 Patches ====== > > 38c5eb93aca9 net: mvpp2: remove useless goto (v4.15-rc1) > > 2d1d7df8a365 net: mvpp2: set the Rx FIFO size depending on the port speeds for > > PPv2.2 (v4.15-rc1) > > 7c10f9742d76 net: mvpp2: initialize the Tx FIFO size (v4.15-rc1) > > 1d7d15d79fb4 net: mvpp2: initialize the RSS tables (v4.15-rc1) > > 1d17db08c056 net: mvpp2: limit TSO segments and use stop/wake thresholds > > (v4.15-rc1) > > 02856a3ba633 net: mvpp2: use the aggr txq size define everywhere (v4.15-rc1) > > 6eb5d375cefc net: mvpp2: simplify the Tx desc set DMA logic (v4.15-rc1) > > 118d6298f6f0 net: mvpp2: add ethtool GOP statistics (v4.15-rc1) > > e5c500eb298a net: mvpp2: fix GOP statistics loop start and stop conditions > > (v4.15-rc1) > > ba2d8d887d96 net: mvpp2: fix the txq_init error path (v4.15-rc2) > > 26146b0e6b68 net: mvpp2: cleanup probed ports in the probe error path > > (v4.15-rc2) > > e749aca84b10 net: mvpp2: do not disable GMAC padding (v4.15-rc2) > > 76e583c5f50e net: mvpp2: check ethtool sets the Tx ring size is to a valid min > > value (v4.15-rc2) > > a154f8e399a0 net: mvpp2: allocate zeroed tx descriptors (v4.15-rc3) > > 8a7b741e76cd net: mvpp2: fix the RSS table entry offset (v4.15-rc3) > > b70d4a5195c7 net: mvpp2: only free the TSO header buffers when it was allocated > > (v4.16-rc1) > > 7cf87e4a5c2b net: mvpp2: split the max ring size from the default one > > (v4.16-rc1) > > 385c284fee84 net: mvpp2: align values in ethtool get_coalesce (v4.16-rc1) > > 24b28ccb8575 net: mvpp2: report the tx-usec coalescing information to ethtool > > (v4.16-rc1) > > 86162281c25f net: mvpp2: adjust the coalescing parameters (v4.16-rc1) > > babe2dbb28e7 device property: Introduce fwnode_get_mac_address() (v4.16-rc1) > > b28f263b8670 device property: Introduce fwnode_get_phy_mode() (v4.16-rc1) > > 7c6c57f2ab2c device property: Introduce fwnode_irq_get() (v4.16-rc1) > > 3395de96ae59 device property: Allow iterating over available child fwnodes > > (v4.16-rc1) > > bf147153d7f4 net: mvpp2: simplify maintaining enabled ports' list (v4.16-rc1) > > 248122212f68 net: mvpp2: use device_*/fwnode_* APIs instead of of_* (v4.16-rc1) > > a75edc7c2eab net: mvpp2: enable ACPI support in the driver (v4.16-rc1) > > 7ac8ff95f48c mvpp2: fix multicast address filter (v4.16-rc3) > > 56beda3db602 net: mvpp2: Add hardware offloading for VLAN filtering (v4.17-rc1) > > 01d049366529 net: mvpp2: use the same buffer pool for all ports (v4.17-rc1) > > effbf5f58d64 net: mvpp2: update the BM buffer free/destroy logic (v4.17-rc1) > > 93ff130f1c2b net: mvpp2: use a data size of 10kB for Tx FIFO on port 0 > > (v4.17-rc1) > > 381c56712db4 net: mvpp2: enable UDP/TCP checksum over IPv6 (v4.17-rc1) > > 576193f2d579 net: mvpp2: jumbo frames support (v4.17-rc1) > > 6e61e10a8a96 net: mvpp2: mvpp2_check_hw_buf_num() can be static (v4.17-rc1) > > ce2a27c761ac net: mvpp2: Simplify MAC filtering function parameters (v4.17-rc1) > > 10fea26ce2aa net: mvpp2: Add support for unicast filtering (v4.17-rc1) > > e2e031640b3a net: mvpp2: use correct index on array mvpp2_pools (v4.17-rc1) > > 47e0e14eb1a6 net: mvpp2: Make mvpp2_prs_hw_read a parser entry init function > > (v4.17-rc1) > > 0c6d9b44145d net: mvpp2: Don't use dynamic allocs for local variables > > (v4.17-rc1) > > cdcfeb0fb473 net: mvpp2: Use relaxed I/O in data path (v4.17-rc1) > > 3d92f0b58206 net: mvpp2: Fix parser entry init boundary check (v4.17-rc1) > > 982e05001c47 net: mvpp2: Fix TCAM filter reserved range (v4.17-rc2) > > da42bb271305 net: mvpp2: Fix DMA address mask size (v4.17-rc2) > > 45f972adb7f4 net: mvpp2: Fix clk error path in mvpp2_probe (v4.17-rc4) > > 9af771ced473 net: mvpp2: Fix clock resource by adding missing mg_core_clk > > (v4.17-rc4) > > ====== END OF LIST ============= > > > > > > pon., 13 sie 2018 o 10:50 Marcin Wojtas <mw@semihalf.com <mailto:mw@semihalf.com>> napisał(a): > >> > >> Hi Jim, > >> > >> Would it be possible, that you take a look at my questions form the > >> previous email? > >> > >> Thanks in advance, > >> Marcin > >> > >> śr., 1 sie 2018 o 17:11 Marcin Wojtas <mw@semihalf.com <mailto:mw@semihalf.com>> napisał(a): > >>> > >>> Hi Jim, > >>> > >>> wt., 31 lip 2018 o 18:09 Jim Perrin <jperrin@centos.org <mailto:jperrin@centos.org>> napisał(a): > >>>> > >>>> > >>>> > >>>> On 07/30/2018 07:00 AM, Marcin Wojtas wrote: > >>>>> Hi Jim, > >>>>> > >>>>> It's been a while, since I sent the patch. Any objections about merging? > >>>>> > >>>>> Is v4.11 kernel still a valid baseline or for the next releases or we > >>>>> should use v4.14? When is that transition and next release supposed to > >>>>> happen? > >>>>> > >>>> > >>>> The current version of the supported kernel is 4.14, so this would need > >>>> to be updated to support the 4.14 tree. > >>>> > >>> > >>> There is still a gap between vanilla v4.14 version of the driver and > >>> the upstream commits that allow to use it with ACPI (although much > >>> smaller than for v4.11). What is a procedure of providing you the > >>> patches? > >>> > >>>> > >>>> > >>>>> Best regards, > >>>>> Marcinsob., 23 cze 2018 o 08:18 Marcin Wojtas <mw@semihalf.com <mailto:mw@semihalf.com>> napisał(a): > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I'm sending a patch that is applicable on top of the kernel > >>>>>> sig-altarch7-aarch64 branch. It enables ACPI support for the Marvell > >>>>>> Armada7k8k NIC - this required backporting very big amount of patches > >>>>>> (all merged upstream), hence I decided to attach the single commit, > >>>>>> instead of issueing 'git send-email' of it. > >>>>>> > >>>> > >>>> > >>>> Once we got to 4.14, there didn't seem to be a demand for the > >>>> sig-altarch kernel to continue so I left it at the previous version. > >>>> From the sounds of things, you still need it for this to work? > >>> > >>> Is v4.14-based Centos an official version to support aarch64? If yes, > >>> I'd complement this version with the needed patches. > >>> > >>> Btw. if I google 'Centos aarch64' the links point to the altarch/7 > >>> images. What is their kernel base then? In other words, where should > >>> one search > >>> for most recent image of aarch64 images? Is there any public release > >>> schedule available? > >>> > >>> About sig-altarch tree, I'd need to make sure internally. From your > >>> perspective, would it be recommended? > >>> > >>>> > >>>>>> Despite many attempts I wasn't able to build entire rpm package with > >>>>>> the mock build utility, however I managed to test the clean kernel > >>>>>> v4.11 with applied all patches and built with updated .config. Please > >>>>>> let know if this patch is sufficient and can be merged. > >>>> > >>>> I'm guessing no unless it patches/builds against 4.14 as well. I'll see > >>>> about updating the sig-altarch tree so that we can test there. > >>>> > >>> > >>> For sure I need to send updated patch list for v4.14. Please see my > >>> question above. > >>> > >>> Thanks, > >>> Marcin > > > You can send me the individual patches directly. Make sure they apply > against the latest kernel-alt: > > https://git.centos.org/summary/rpms!kernel-alt.git <https://git.centos.org/summary/rpms%21kernel-alt.git> > > Thanks, > Johnny Hughes >
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
Hi Johnny,
pt., 28 wrz 2018 o 15:56 Marcin Wojtas mw@semihalf.com napisał(a):
Hi Johnny,
Thank you for the information.
pt., 28 wrz 2018 o 13:02 Johnny Hughes johnny@centos.org napisał(a):
Marcin,
I have added these patches to the new kernel that I am going to release later today.
There seemed to be some new config entries (other than just the 3 you specified). I think I enabled everything and created modules for them for aarch64.
Please take a look at the new kernel and make sure the config is like you want it.
kernel-alt-4.14.0-49.13.1.el7a.src.rpm on target c7.1804.u.aarch64
I checked the config in the build.log and everything seems in place.
(It should be signed and released in a couple hours, I am still going to do a boot test on a real machine .. I already booted it in a VM)
What will be the easiest way to test it? Do you publish some kind of daily build isos, that one can burn and install?
Is the new build available publicly? What is the easiest way to try it out on my target machine?
Thanks, Marcin
Best regards, Marcin
Thanks, Johnny Hughes
On 09/11/2018 08:34 AM, Marcin Wojtas wrote:
Hi Johny,
Were you able to take a look at the patches?
Best regards, Marcin
wt., 4 wrz 2018 o 18:22 Marcin Wojtas <mw@semihalf.com mailto:mw@semihalf.com> napisał(a):
Hi Johnny, I attach all patches, they will easily apply (git am centos_mvpp2/*) onto v4.14.0 baseline. Also a kernel-alt-4.14.0-aarch64.config file must be updated with following additions: +CONFIG_ARCH_MVEBU=y +CONFIG_MVPP2=m +CONFIG_MARVELL_10G_PHY=m For reference I attach the config file as well (I took kernel-alt-4.14.0-aarch64.config from top of c7-alt branch to v4.14.0 baseline, enabled 3 configs as above and saved). Please let know if you need any help. About testing, what would be the easiest way to try full centos image with the kernel? Install the latest available iso from: http://mirror.centos.org/altarch/7/isos/aarch64/ and run kernel update? Or a different way is recommended? Thanks, Marcin wt., 4 wrz 2018 o 15:00 Johnny Hughes <johnny@centos.org <mailto:johnny@centos.org>> napisał(a): > > On 09/03/2018 09:24 AM, Marcin Wojtas wrote: > > Hi Jim, > > > > I've prepared list of mainline patches, that smoothely apply onto > > v4.14 baseline. The NIC is working with ACPI as expected. > > Because it's not clear to me, how patches should be submitted (please > > see my questions from previous emails), below you can find a full > > list. > > > > Please let know, how can we proceed from here and how possibly could I > > test real Centos image with patches applied. > > > > Thanks, > > Marcin > > > > ====== LIST of MVPP2 Patches ====== > > 38c5eb93aca9 net: mvpp2: remove useless goto (v4.15-rc1) > > 2d1d7df8a365 net: mvpp2: set the Rx FIFO size depending on the port speeds for > > PPv2.2 (v4.15-rc1) > > 7c10f9742d76 net: mvpp2: initialize the Tx FIFO size (v4.15-rc1) > > 1d7d15d79fb4 net: mvpp2: initialize the RSS tables (v4.15-rc1) > > 1d17db08c056 net: mvpp2: limit TSO segments and use stop/wake thresholds > > (v4.15-rc1) > > 02856a3ba633 net: mvpp2: use the aggr txq size define everywhere (v4.15-rc1) > > 6eb5d375cefc net: mvpp2: simplify the Tx desc set DMA logic (v4.15-rc1) > > 118d6298f6f0 net: mvpp2: add ethtool GOP statistics (v4.15-rc1) > > e5c500eb298a net: mvpp2: fix GOP statistics loop start and stop conditions > > (v4.15-rc1) > > ba2d8d887d96 net: mvpp2: fix the txq_init error path (v4.15-rc2) > > 26146b0e6b68 net: mvpp2: cleanup probed ports in the probe error path > > (v4.15-rc2) > > e749aca84b10 net: mvpp2: do not disable GMAC padding (v4.15-rc2) > > 76e583c5f50e net: mvpp2: check ethtool sets the Tx ring size is to a valid min > > value (v4.15-rc2) > > a154f8e399a0 net: mvpp2: allocate zeroed tx descriptors (v4.15-rc3) > > 8a7b741e76cd net: mvpp2: fix the RSS table entry offset (v4.15-rc3) > > b70d4a5195c7 net: mvpp2: only free the TSO header buffers when it was allocated > > (v4.16-rc1) > > 7cf87e4a5c2b net: mvpp2: split the max ring size from the default one > > (v4.16-rc1) > > 385c284fee84 net: mvpp2: align values in ethtool get_coalesce (v4.16-rc1) > > 24b28ccb8575 net: mvpp2: report the tx-usec coalescing information to ethtool > > (v4.16-rc1) > > 86162281c25f net: mvpp2: adjust the coalescing parameters (v4.16-rc1) > > babe2dbb28e7 device property: Introduce fwnode_get_mac_address() (v4.16-rc1) > > b28f263b8670 device property: Introduce fwnode_get_phy_mode() (v4.16-rc1) > > 7c6c57f2ab2c device property: Introduce fwnode_irq_get() (v4.16-rc1) > > 3395de96ae59 device property: Allow iterating over available child fwnodes > > (v4.16-rc1) > > bf147153d7f4 net: mvpp2: simplify maintaining enabled ports' list (v4.16-rc1) > > 248122212f68 net: mvpp2: use device_*/fwnode_* APIs instead of of_* (v4.16-rc1) > > a75edc7c2eab net: mvpp2: enable ACPI support in the driver (v4.16-rc1) > > 7ac8ff95f48c mvpp2: fix multicast address filter (v4.16-rc3) > > 56beda3db602 net: mvpp2: Add hardware offloading for VLAN filtering (v4.17-rc1) > > 01d049366529 net: mvpp2: use the same buffer pool for all ports (v4.17-rc1) > > effbf5f58d64 net: mvpp2: update the BM buffer free/destroy logic (v4.17-rc1) > > 93ff130f1c2b net: mvpp2: use a data size of 10kB for Tx FIFO on port 0 > > (v4.17-rc1) > > 381c56712db4 net: mvpp2: enable UDP/TCP checksum over IPv6 (v4.17-rc1) > > 576193f2d579 net: mvpp2: jumbo frames support (v4.17-rc1) > > 6e61e10a8a96 net: mvpp2: mvpp2_check_hw_buf_num() can be static (v4.17-rc1) > > ce2a27c761ac net: mvpp2: Simplify MAC filtering function parameters (v4.17-rc1) > > 10fea26ce2aa net: mvpp2: Add support for unicast filtering (v4.17-rc1) > > e2e031640b3a net: mvpp2: use correct index on array mvpp2_pools (v4.17-rc1) > > 47e0e14eb1a6 net: mvpp2: Make mvpp2_prs_hw_read a parser entry init function > > (v4.17-rc1) > > 0c6d9b44145d net: mvpp2: Don't use dynamic allocs for local variables > > (v4.17-rc1) > > cdcfeb0fb473 net: mvpp2: Use relaxed I/O in data path (v4.17-rc1) > > 3d92f0b58206 net: mvpp2: Fix parser entry init boundary check (v4.17-rc1) > > 982e05001c47 net: mvpp2: Fix TCAM filter reserved range (v4.17-rc2) > > da42bb271305 net: mvpp2: Fix DMA address mask size (v4.17-rc2) > > 45f972adb7f4 net: mvpp2: Fix clk error path in mvpp2_probe (v4.17-rc4) > > 9af771ced473 net: mvpp2: Fix clock resource by adding missing mg_core_clk > > (v4.17-rc4) > > ====== END OF LIST ============= > > > > > > pon., 13 sie 2018 o 10:50 Marcin Wojtas <mw@semihalf.com <mailto:mw@semihalf.com>> napisał(a): > >> > >> Hi Jim, > >> > >> Would it be possible, that you take a look at my questions form the > >> previous email? > >> > >> Thanks in advance, > >> Marcin > >> > >> śr., 1 sie 2018 o 17:11 Marcin Wojtas <mw@semihalf.com <mailto:mw@semihalf.com>> napisał(a): > >>> > >>> Hi Jim, > >>> > >>> wt., 31 lip 2018 o 18:09 Jim Perrin <jperrin@centos.org <mailto:jperrin@centos.org>> napisał(a): > >>>> > >>>> > >>>> > >>>> On 07/30/2018 07:00 AM, Marcin Wojtas wrote: > >>>>> Hi Jim, > >>>>> > >>>>> It's been a while, since I sent the patch. Any objections about merging? > >>>>> > >>>>> Is v4.11 kernel still a valid baseline or for the next releases or we > >>>>> should use v4.14? When is that transition and next release supposed to > >>>>> happen? > >>>>> > >>>> > >>>> The current version of the supported kernel is 4.14, so this would need > >>>> to be updated to support the 4.14 tree. > >>>> > >>> > >>> There is still a gap between vanilla v4.14 version of the driver and > >>> the upstream commits that allow to use it with ACPI (although much > >>> smaller than for v4.11). What is a procedure of providing you the > >>> patches? > >>> > >>>> > >>>> > >>>>> Best regards, > >>>>> Marcinsob., 23 cze 2018 o 08:18 Marcin Wojtas <mw@semihalf.com <mailto:mw@semihalf.com>> napisał(a): > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I'm sending a patch that is applicable on top of the kernel > >>>>>> sig-altarch7-aarch64 branch. It enables ACPI support for the Marvell > >>>>>> Armada7k8k NIC - this required backporting very big amount of patches > >>>>>> (all merged upstream), hence I decided to attach the single commit, > >>>>>> instead of issueing 'git send-email' of it. > >>>>>> > >>>> > >>>> > >>>> Once we got to 4.14, there didn't seem to be a demand for the > >>>> sig-altarch kernel to continue so I left it at the previous version. > >>>> From the sounds of things, you still need it for this to work? > >>> > >>> Is v4.14-based Centos an official version to support aarch64? If yes, > >>> I'd complement this version with the needed patches. > >>> > >>> Btw. if I google 'Centos aarch64' the links point to the altarch/7 > >>> images. What is their kernel base then? In other words, where should > >>> one search > >>> for most recent image of aarch64 images? Is there any public release > >>> schedule available? > >>> > >>> About sig-altarch tree, I'd need to make sure internally. From your > >>> perspective, would it be recommended? > >>> > >>>> > >>>>>> Despite many attempts I wasn't able to build entire rpm package with > >>>>>> the mock build utility, however I managed to test the clean kernel > >>>>>> v4.11 with applied all patches and built with updated .config. Please > >>>>>> let know if this patch is sufficient and can be merged. > >>>> > >>>> I'm guessing no unless it patches/builds against 4.14 as well. I'll see > >>>> about updating the sig-altarch tree so that we can test there. > >>>> > >>> > >>> For sure I need to send updated patch list for v4.14. Please see my > >>> question above. > >>> > >>> Thanks, > >>> Marcin > > > You can send me the individual patches directly. Make sure they apply > against the latest kernel-alt: > > https://git.centos.org/summary/rpms!kernel-alt.git <https://git.centos.org/summary/rpms%21kernel-alt.git> > > Thanks, > Johnny Hughes >
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
On 10/02/2018 04:48 AM, Marcin Wojtas wrote:
Hi Johnny,
pt., 28 wrz 2018 o 15:56 Marcin Wojtas mw@semihalf.com napisał(a):
Hi Johnny,
Thank you for the information.
pt., 28 wrz 2018 o 13:02 Johnny Hughes johnny@centos.org napisał(a):
Marcin,
I have added these patches to the new kernel that I am going to release later today.
There seemed to be some new config entries (other than just the 3 you specified). I think I enabled everything and created modules for them for aarch64.
Please take a look at the new kernel and make sure the config is like you want it.
kernel-alt-4.14.0-49.13.1.el7a.src.rpm on target c7.1804.u.aarch64
I checked the config in the build.log and everything seems in place.
(It should be signed and released in a couple hours, I am still going to do a boot test on a real machine .. I already booted it in a VM)
What will be the easiest way to test it? Do you publish some kind of daily build isos, that one can burn and install?
Is the new build available publicly? What is the easiest way to try it out on my target machine?
Thanks, Marcin
Yes,
kernel-alt-4.14.0-49.13.1.el7a in the main repo has all the patches and a new config file for aarch64 rolled in.
It passed all out post update tests, so it is released.
If any adjustment is need, submit patches here.
Thanks, Johnny Hughes
<snip>
wt., 2 paź 2018 o 16:53 Johnny Hughes johnny@centos.org napisał(a):
On 10/02/2018 04:48 AM, Marcin Wojtas wrote:
Hi Johnny,
pt., 28 wrz 2018 o 15:56 Marcin Wojtas mw@semihalf.com napisał(a):
Hi Johnny,
Thank you for the information.
pt., 28 wrz 2018 o 13:02 Johnny Hughes johnny@centos.org napisał(a):
Marcin,
I have added these patches to the new kernel that I am going to release later today.
There seemed to be some new config entries (other than just the 3 you specified). I think I enabled everything and created modules for them for aarch64.
Please take a look at the new kernel and make sure the config is like you want it.
kernel-alt-4.14.0-49.13.1.el7a.src.rpm on target c7.1804.u.aarch64
I checked the config in the build.log and everything seems in place.
(It should be signed and released in a couple hours, I am still going to do a boot test on a real machine .. I already booted it in a VM)
What will be the easiest way to test it? Do you publish some kind of daily build isos, that one can burn and install?
Is the new build available publicly? What is the easiest way to try it out on my target machine?
Thanks, Marcin
Yes,
kernel-alt-4.14.0-49.13.1.el7a in the main repo has all the patches and a new config file for aarch64 rolled in.
Thanks, my question is pretty much entry-level: - what is the location of the most recent iso of Centos? - how to upgrade its kernel to kernel-alt-4.14.0-49.13.1.el7a
Best regards, Marcin
It passed all out post update tests, so it is released.
If any adjustment is need, submit patches here.
Thanks, Johnny Hughes
<snip>
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
On 10/02/2018 10:12 AM, Marcin Wojtas wrote:
Thanks, my question is pretty much entry-level:
- what is the location of the most recent iso of Centos?
- how to upgrade its kernel to kernel-alt-4.14.0-49.13.1.el7a
The aarch64 isos live here:
http://mirror.centos.org/altarch/7/isos/aarch64/
Minimal iso will create an minimal install (basically, bootable with network, firewall, etc) and I normally use it as a basis to install anything else.
Once you have a bootable install, this command will update to the latest everything that is installed (including kernel):
yum update
Once you have the update done, reboot and you will be running the latest kernel.
Then you can install whatever else you want on the machine with yum.
If you search on google fro 'yum centos' you will find many tutorials on how to do things, they are applicable to aarch64 as well as other arches.
Here is one (ignore the subscription manager stuff .. that is for RHEL and not CentOS):
https://www.cyberciti.biz/faq/rhel-centos-fedora-linux-yum-command-howto/
śr., 3 paź 2018 o 15:44 Johnny Hughes johnny@centos.org napisał(a):
On 10/02/2018 10:12 AM, Marcin Wojtas wrote:
Thanks, my question is pretty much entry-level:
- what is the location of the most recent iso of Centos?
- how to upgrade its kernel to kernel-alt-4.14.0-49.13.1.el7a
The aarch64 isos live here:
http://mirror.centos.org/altarch/7/isos/aarch64/
Minimal iso will create an minimal install (basically, bootable with network, firewall, etc) and I normally use it as a basis to install anything else.
Once you have a bootable install, this command will update to the latest everything that is installed (including kernel):
yum update
Once you have the update done, reboot and you will be running the latest kernel.
Then you can install whatever else you want on the machine with yum.
If you search on google fro 'yum centos' you will find many tutorials on how to do things, they are applicable to aarch64 as well as other arches.
Here is one (ignore the subscription manager stuff .. that is for RHEL and not CentOS):
https://www.cyberciti.biz/faq/rhel-centos-fedora-linux-yum-command-howto/
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
śr., 3 paź 2018 o 16:09 Marcin Wojtas mw@semihalf.com napisał(a):
śr., 3 paź 2018 o 15:44 Johnny Hughes johnny@centos.org napisał(a):
On 10/02/2018 10:12 AM, Marcin Wojtas wrote:
Thanks, my question is pretty much entry-level:
- what is the location of the most recent iso of Centos?
- how to upgrade its kernel to kernel-alt-4.14.0-49.13.1.el7a
The aarch64 isos live here:
http://mirror.centos.org/altarch/7/isos/aarch64/
Minimal iso will create an minimal install (basically, bootable with network, firewall, etc) and I normally use it as a basis to install anything else.
Once you have a bootable install, this command will update to the latest everything that is installed (including kernel):
yum update
Once you have the update done, reboot and you will be running the latest kernel.
Then you can install whatever else you want on the machine with yum.
If you search on google fro 'yum centos' you will find many tutorials on how to do things, they are applicable to aarch64 as well as other arches.
Here is one (ignore the subscription manager stuff .. that is for RHEL and not CentOS):
https://www.cyberciti.biz/faq/rhel-centos-fedora-linux-yum-command-howto/
Thanks a lot, will try it! Marcin
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
śr., 3 paź 2018 o 16:10 Marcin Wojtas mw@semihalf.com napisał(a):
śr., 3 paź 2018 o 16:09 Marcin Wojtas mw@semihalf.com napisał(a):
śr., 3 paź 2018 o 15:44 Johnny Hughes johnny@centos.org napisał(a):
On 10/02/2018 10:12 AM, Marcin Wojtas wrote:
Thanks, my question is pretty much entry-level:
- what is the location of the most recent iso of Centos?
- how to upgrade its kernel to kernel-alt-4.14.0-49.13.1.el7a
The aarch64 isos live here:
http://mirror.centos.org/altarch/7/isos/aarch64/
Minimal iso will create an minimal install (basically, bootable with network, firewall, etc) and I normally use it as a basis to install anything else.
Once you have a bootable install, this command will update to the latest everything that is installed (including kernel):
yum update
Once you have the update done, reboot and you will be running the latest kernel.
Then you can install whatever else you want on the machine with yum.
If you search on google fro 'yum centos' you will find many tutorials on how to do things, they are applicable to aarch64 as well as other arches.
Here is one (ignore the subscription manager stuff .. that is for RHEL and not CentOS):
https://www.cyberciti.biz/faq/rhel-centos-fedora-linux-yum-command-howto/
Everything works fine, easily I got the integrated NICs working: [root@localhost ~]# ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 2048 link/ether 92:5c:6d:42:49:07 brd ff:ff:ff:ff:ff:ff 3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 2048 link/ether b6:e8:ad:2a:c1:33 brd ff:ff:ff:ff:ff:ff 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 2048 link/ether ee:c5:4a:d3:c7:07 brd ff:ff:ff:ff:ff:ff 5: enp0s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
During the installation, I only had to add 'console=ttyS0,115200' to the commandline, otherwise there was no output. Afterwards however, it boots without any intervention.
Thanks, Marcin
Hello,
is there a package called "g++-arm-linux-gnueabihf" available for centos on rpi?
thanks,
Ron
Hello ,
I had to replace my router etc, and set everything up (SSID ip addresses etc) like it used to be.
However, now when I boot a raspberry pi 3b, I get a "IPv6 wlan0 link is not ready." while ipv6 is turned off?
(I tried to create a new centos image on an SD, but somehow thatdoesn't work. where is the latest working version of it?)
is there a way to fix this wlan0 error ?
thanks,
Ron
On 1/5/20 21:52, R C wrote:
Hello ,
I had to replace my router etc, and set everything up (SSID ip addresses etc) like it used to be.
However, now when I boot a raspberry pi 3b, I get a "IPv6 wlan0 link is not ready." while ipv6 is turned off?
Turned off how?
(I tried to create a new centos image on an SD, but somehow thatdoesn't work. where is the latest working version of it?)
Which image doesn't work? All the latest versions are in http://mirror.centos.org/altarch/7/isos/armhfp/
is there a way to fix this wlan0 error ?
That depends on how ipv6 is disabled, but even so, that looks more like a warning than an actual error.
thanks,
Ron
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
Pablo.
Hello,
the HW/MAC address on a new installation,RPI, seems to change on a wireless adapter every time I reboot it.
I have seen that issue before, a long time go, thought that error was gone by now. Back then I 'fixed' it with some changes in a boot file, but forgot
how that was done again.
Does anyone have any pointers for that?
thanks,
Ron
I just notice that NetworkManager might be doing that?
On 5/26/20 9:29 AM, R C wrote:
Hello,
the HW/MAC address on a new installation,RPI, seems to change on a wireless adapter every time I reboot it.
I have seen that issue before, a long time go, thought that error was gone by now. Back then I 'fixed' it with some changes in a boot file, but forgot
how that was done again.
Does anyone have any pointers for that?
thanks,
Ron