| Message ID | 20230220115913.25811-1-paul.gortmaker@windriver.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Remove some e300/MPC83xx evaluation platforms | expand |
> -----Original Message----- > From: Paul Gortmaker <paul.gortmaker@windriver.com> > Sent: Monday, February 20, 2023 5:59 AM > To: linuxppc-dev@lists.ozlabs.org > Cc: Leo Li <leoyang.li@nxp.com>; Claudiu Manoil <claudiu.manoil@nxp.com>; > Paul Gortmaker <paul.gortmaker@windriver.com>; Scott Wood > <oss@buserror.net>; Michael Ellerman <mpe@ellerman.id.au>; Benjamin > Herrenschmidt <benh@kernel.crashing.org>; Paul Mackerras > <paulus@samba.org> > Subject: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms > > [This RFC is proposed for v6.4 and hence is based off linux-next.] > > This series removes support for four e300 (MPC83xx) Freescale processor > family evaluation boards that were added to the kernel in the 2006 era. Thanks. Let me discuss this with our marketing team to see if they have any valid reason to keep them around. > > These boards were all of a very similar form factor, a largish PCI or PCI-X card > that could also be used standalone with an external power brick, and all > shared the Modular Development System (MDS) designation. > > These platforms were made in limited quantity and were generally designed > to get early silicon into the hands of OEMs who would later develop their > own boards/platforms. As such, availability was limited to those who would > be working on boards and/or BSP support. > > Many early revision MDS platforms used a mechanical clamping system to > hold the BGA CPU in place to facilitate CPU updates -- something not > normally possible for a soldered down BGA in a COTS system. > > The point of these details is to give context that reflects that these four > boards were made in limited quantities, were not in a form factor that is > really "hobbyist" friendly and hence make sense for removal 17 years later. > > Here, we remove the MPC8548E-MDS[1], the MPC8360E-MDS[2], the > MPC837xE-MDS[3], and the MPC832x-MDS[4] board support from the kernel. > > There will still exist several e300 Freescale Reference Design System (RDS) > boards[5] and mini-ITX boards[6] with support in the kernel. While these > were more of a COTS "ready to deploy" design more suited to hobbyists, it > probably makes sense to consider removing these as well, based on age. > > But before we get to that, lets see how this goes -- and then we should look > at similar early e500 evaluation platforms [MPC8540-ADS, etc] next, as the > oldest there date back to 2002[7] -- before considering RDB/mITX. > > I intentionally didn't put any links in the commits, since as we all know, they > tend not to be stable long term, so keep them here in the merge data. > Credit to NXP for keeping around these old legacy docs this long! > > Paul. > > -- > > [1] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .nxp.com%2Fdesign%2Fqoriq-developer-resources%2Fmpc8349e-modular- > development- > system%3AMPC8349EMDS&data=05%7C01%7Cleoyang.li%40nxp.com%7Ca2 > 820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301635% > 7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 > 0%7C%7C%7C&sdata=Q4COgwpjsE4mHXvl9HdGo3otPCYML3z%2FR6IoCEYRE > wg%3D&reserved=0 > [2] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .nxp.com%2Fdocs%2Fen%2Fuser- > guide%2FMPC8360EMDSUM.pdf&data=05%7C01%7Cleoyang.li%40nxp.com > %7Ca2820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c30 > 1635%7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8ey > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% > 7C3000%7C%7C%7C&sdata=JyLT0MfGAHQ8a%2FNgpLdVFtyACkwPR%2FOkB > yN1aW0wySs%3D&reserved=0 > [3] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .nxp.com%2Fproducts%2Fprocessors-and-microcontrollers%2Flegacy-mpu- > mcus%2Fpowerquicc-processors%2Fpowerquicc-iii-mpc85xx%2Fmpc837xe- > modular-development- > system%3AMPC837XEMDS&data=05%7C01%7Cleoyang.li%40nxp.com%7Ca2 > 820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301635% > 7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 > 0%7C%7C%7C&sdata=052dpEEcGmbuhRLnMDCNoOkTeguF%2BPA0oJGNvV1 > jSjI%3D&reserved=0 > [4] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .nxp.com%2Fproducts%2Fprocessors-and-microcontrollers%2Flegacy-mpu- > mcus%2Fpowerquicc-processors%2Fpowerquicc-ii-pro-mpc83xx%2Flow- > power-powerquicc-ii-pro-processor-with-ddr2-tdm-pci-security-usb-quicc- > engine-with- > utopia%3AMPC8323E&data=05%7C01%7Cleoyang.li%40nxp.com%7Ca2820c1 > e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0% > 7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7 > C%7C%7C&sdata=mZQh%2FogNgNUb0wNJV972kYIDvn61gx0TWNd1u1d7PZ > Q%3D&reserved=0 > [5] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .nxp.com%2Fdocs%2Fen%2Ffact- > sheet%2FMPC8379ERDBFS.pdf&data=05%7C01%7Cleoyang.li%40nxp.com%7 > Ca2820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c3016 > 35%7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJ > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% > 7C3000%7C%7C%7C&sdata=EJmP6Regr7zpvYvHUmX64h3LZSaBT3Mb1h%2BN > KQT%2FUls%3D&reserved=0 > [6] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .digikey.ca%2Fen%2Fproducts%2Fdetail%2Fnxp-usa-inc%2FMPC8349E-MITX- > GP%2F1204733&data=05%7C01%7Cleoyang.li%40nxp.com%7Ca2820c1e44264 > 0c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7 > C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw > MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C% > 7C&sdata=hw6IQDUaXH6huQFCnCkFIbNfj1xMrq%2FanDMUU%2FXZYQg%3 > D&reserved=0 > [7] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .nxp.com%2Fdocs%2Fen%2Freference- > manual%2FMPC8560ADSUG.pdf&data=05%7C01%7Cleoyang.li%40nxp.com% > 7Ca2820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301 > 635%7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJ > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% > 7C3000%7C%7C%7C&sdata=Ed%2BZR07y9Sp8xx5H47SAXzk9ET73creygxk%2B > emmbfuA%3D&reserved=0 > > Cc: Scott Wood <oss@buserror.net> > Cc: Michael Ellerman <mpe@ellerman.id.au> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> > Cc: Paul Mackerras <paulus@samba.org> > Cc: Li Yang <leoyang.li@nxp.com> > Cc: Claudiu Manoil <claudiu.manoil@nxp.com> > > --- > > Paul Gortmaker (4): > powerpc: drop MPC834x_MDS platform support > powerpc: drop MPC836x_MDS platform support > powerpc: drop MPC837x_MDS platform support > powerpc: drop MPC832x_MDS platform support > > arch/powerpc/boot/Makefile | 1 - > arch/powerpc/boot/dts/mpc832x_mds.dts | 436 --------------- > arch/powerpc/boot/dts/mpc834x_mds.dts | 403 -------------- > arch/powerpc/boot/dts/mpc836x_mds.dts | 481 ----------------- > arch/powerpc/boot/dts/mpc8377_mds.dts | 505 ------------------ > arch/powerpc/boot/dts/mpc8378_mds.dts | 489 ----------------- > arch/powerpc/boot/dts/mpc8379_mds.dts | 455 ---------------- > .../configs/83xx/mpc832x_mds_defconfig | 59 -- > .../configs/83xx/mpc834x_mds_defconfig | 58 -- > .../configs/83xx/mpc836x_mds_defconfig | 64 --- > .../configs/83xx/mpc837x_mds_defconfig | 58 -- > arch/powerpc/configs/mpc83xx_defconfig | 4 - > arch/powerpc/configs/ppc6xx_defconfig | 4 - > arch/powerpc/platforms/83xx/Kconfig | 32 -- > arch/powerpc/platforms/83xx/Makefile | 4 - > arch/powerpc/platforms/83xx/mpc832x_mds.c | 110 ---- > arch/powerpc/platforms/83xx/mpc834x_mds.c | 101 ---- > arch/powerpc/platforms/83xx/mpc836x_mds.c | 210 -------- > arch/powerpc/platforms/83xx/mpc837x_mds.c | 103 ---- > 19 files changed, 3577 deletions(-) > delete mode 100644 arch/powerpc/boot/dts/mpc832x_mds.dts > delete mode 100644 arch/powerpc/boot/dts/mpc834x_mds.dts > delete mode 100644 arch/powerpc/boot/dts/mpc836x_mds.dts > delete mode 100644 arch/powerpc/boot/dts/mpc8377_mds.dts > delete mode 100644 arch/powerpc/boot/dts/mpc8378_mds.dts > delete mode 100644 arch/powerpc/boot/dts/mpc8379_mds.dts > delete mode 100644 arch/powerpc/configs/83xx/mpc832x_mds_defconfig > delete mode 100644 arch/powerpc/configs/83xx/mpc834x_mds_defconfig > delete mode 100644 arch/powerpc/configs/83xx/mpc836x_mds_defconfig > delete mode 100644 arch/powerpc/configs/83xx/mpc837x_mds_defconfig > delete mode 100644 arch/powerpc/platforms/83xx/mpc832x_mds.c > delete mode 100644 arch/powerpc/platforms/83xx/mpc834x_mds.c > delete mode 100644 arch/powerpc/platforms/83xx/mpc836x_mds.c > delete mode 100644 arch/powerpc/platforms/83xx/mpc837x_mds.c > > -- > 2.17.1
> -----Original Message----- > From: Paul Gortmaker <paul.gortmaker@windriver.com> > Sent: Monday, February 20, 2023 5:59 AM > To: linuxppc-dev@lists.ozlabs.org > Cc: Leo Li <leoyang.li@nxp.com>; Claudiu Manoil <claudiu.manoil@nxp.com>; > Paul Gortmaker <paul.gortmaker@windriver.com>; Scott Wood > <oss@buserror.net>; Michael Ellerman <mpe@ellerman.id.au>; Benjamin > Herrenschmidt <benh@kernel.crashing.org>; Paul Mackerras > <paulus@samba.org> > Subject: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms > > [This RFC is proposed for v6.4 and hence is based off linux-next.] > > This series removes support for four e300 (MPC83xx) Freescale processor > family evaluation boards that were added to the kernel in the 2006 era. Hi Paul, I talked with our marketing team on this. Although we do not recommend any new design with these SoCs, they are still being shipped in large amount to customers now. Plus it is possible for the bigger amount of existing devices to be updating their software that includes a new kernel. So we should definitely keep all the common SoC code that might be needed to support their own design. > > These boards were all of a very similar form factor, a largish PCI or PCI-X card > that could also be used standalone with an external power brick, and all > shared the Modular Development System (MDS) designation. > > These platforms were made in limited quantity and were generally designed > to get early silicon into the hands of OEMs who would later develop their > own boards/platforms. As such, availability was limited to those who would > be working on boards and/or BSP support. > > Many early revision MDS platforms used a mechanical clamping system to > hold the BGA CPU in place to facilitate CPU updates -- something not > normally possible for a soldered down BGA in a COTS system. > > The point of these details is to give context that reflects that these four > boards were made in limited quantities, were not in a form factor that is > really "hobbyist" friendly and hence make sense for removal 17 years later. We would agree with you that the MDS platforms are only used by a limited number of customers for evaluation purpose, so it should be fine to be removed. So for this series: Acked-by: Li Yang <leoyang.li@nxp.com> > > Here, we remove the MPC8548E-MDS[1], the MPC8360E-MDS[2], the > MPC837xE-MDS[3], and the MPC832x-MDS[4] board support from the kernel. > > There will still exist several e300 Freescale Reference Design System (RDS) > boards[5] and mini-ITX boards[6] with support in the kernel. While these > were more of a COTS "ready to deploy" design more suited to hobbyists, it > probably makes sense to consider removing these as well, based on age. These boards are mass market boards that sold in larger amount and are much more likely to still be used. We would suggest we keep them for now. > > But before we get to that, lets see how this goes -- and then we should look > at similar early e500 evaluation platforms [MPC8540-ADS, etc] next, as the > oldest there date back to 2002[7] -- before considering RDB/mITX. > > I intentionally didn't put any links in the commits, since as we all know, they > tend not to be stable long term, so keep them here in the merge data. > Credit to NXP for keeping around these old legacy docs this long! > > Paul. > > -- > > [1] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .nxp.com%2Fdesign%2Fqoriq-developer-resources%2Fmpc8349e-modular- > development- > system%3AMPC8349EMDS&data=05%7C01%7Cleoyang.li%40nxp.com%7Ca2 > 820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301635% > 7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 > 0%7C%7C%7C&sdata=Q4COgwpjsE4mHXvl9HdGo3otPCYML3z%2FR6IoCEYRE > wg%3D&reserved=0 > [2] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .nxp.com%2Fdocs%2Fen%2Fuser- > guide%2FMPC8360EMDSUM.pdf&data=05%7C01%7Cleoyang.li%40nxp.com > %7Ca2820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c30 > 1635%7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8ey > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% > 7C3000%7C%7C%7C&sdata=JyLT0MfGAHQ8a%2FNgpLdVFtyACkwPR%2FOkB > yN1aW0wySs%3D&reserved=0 > [3] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .nxp.com%2Fproducts%2Fprocessors-and-microcontrollers%2Flegacy-mpu- > mcus%2Fpowerquicc-processors%2Fpowerquicc-iii-mpc85xx%2Fmpc837xe- > modular-development- > system%3AMPC837XEMDS&data=05%7C01%7Cleoyang.li%40nxp.com%7Ca2 > 820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301635% > 7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 > 0%7C%7C%7C&sdata=052dpEEcGmbuhRLnMDCNoOkTeguF%2BPA0oJGNvV1 > jSjI%3D&reserved=0 > [4] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .nxp.com%2Fproducts%2Fprocessors-and-microcontrollers%2Flegacy-mpu- > mcus%2Fpowerquicc-processors%2Fpowerquicc-ii-pro-mpc83xx%2Flow- > power-powerquicc-ii-pro-processor-with-ddr2-tdm-pci-security-usb-quicc- > engine-with- > utopia%3AMPC8323E&data=05%7C01%7Cleoyang.li%40nxp.com%7Ca2820c1 > e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0% > 7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7 > C%7C%7C&sdata=mZQh%2FogNgNUb0wNJV972kYIDvn61gx0TWNd1u1d7PZ > Q%3D&reserved=0 > [5] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .nxp.com%2Fdocs%2Fen%2Ffact- > sheet%2FMPC8379ERDBFS.pdf&data=05%7C01%7Cleoyang.li%40nxp.com%7 > Ca2820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c3016 > 35%7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJ > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% > 7C3000%7C%7C%7C&sdata=EJmP6Regr7zpvYvHUmX64h3LZSaBT3Mb1h%2BN > KQT%2FUls%3D&reserved=0 > [6] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .digikey.ca%2Fen%2Fproducts%2Fdetail%2Fnxp-usa-inc%2FMPC8349E-MITX- > GP%2F1204733&data=05%7C01%7Cleoyang.li%40nxp.com%7Ca2820c1e44264 > 0c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7 > C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw > MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C% > 7C&sdata=hw6IQDUaXH6huQFCnCkFIbNfj1xMrq%2FanDMUU%2FXZYQg%3 > D&reserved=0 > [7] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > .nxp.com%2Fdocs%2Fen%2Freference- > manual%2FMPC8560ADSUG.pdf&data=05%7C01%7Cleoyang.li%40nxp.com% > 7Ca2820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301 > 635%7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJ > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% > 7C3000%7C%7C%7C&sdata=Ed%2BZR07y9Sp8xx5H47SAXzk9ET73creygxk%2B > emmbfuA%3D&reserved=0 > > Cc: Scott Wood <oss@buserror.net> > Cc: Michael Ellerman <mpe@ellerman.id.au> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> > Cc: Paul Mackerras <paulus@samba.org> > Cc: Li Yang <leoyang.li@nxp.com> > Cc: Claudiu Manoil <claudiu.manoil@nxp.com> > > --- > > Paul Gortmaker (4): > powerpc: drop MPC834x_MDS platform support > powerpc: drop MPC836x_MDS platform support > powerpc: drop MPC837x_MDS platform support > powerpc: drop MPC832x_MDS platform support > > arch/powerpc/boot/Makefile | 1 - > arch/powerpc/boot/dts/mpc832x_mds.dts | 436 --------------- > arch/powerpc/boot/dts/mpc834x_mds.dts | 403 -------------- > arch/powerpc/boot/dts/mpc836x_mds.dts | 481 ----------------- > arch/powerpc/boot/dts/mpc8377_mds.dts | 505 ------------------ > arch/powerpc/boot/dts/mpc8378_mds.dts | 489 ----------------- > arch/powerpc/boot/dts/mpc8379_mds.dts | 455 ---------------- > .../configs/83xx/mpc832x_mds_defconfig | 59 -- > .../configs/83xx/mpc834x_mds_defconfig | 58 -- > .../configs/83xx/mpc836x_mds_defconfig | 64 --- > .../configs/83xx/mpc837x_mds_defconfig | 58 -- > arch/powerpc/configs/mpc83xx_defconfig | 4 - > arch/powerpc/configs/ppc6xx_defconfig | 4 - > arch/powerpc/platforms/83xx/Kconfig | 32 -- > arch/powerpc/platforms/83xx/Makefile | 4 - > arch/powerpc/platforms/83xx/mpc832x_mds.c | 110 ---- > arch/powerpc/platforms/83xx/mpc834x_mds.c | 101 ---- > arch/powerpc/platforms/83xx/mpc836x_mds.c | 210 -------- > arch/powerpc/platforms/83xx/mpc837x_mds.c | 103 ---- > 19 files changed, 3577 deletions(-) > delete mode 100644 arch/powerpc/boot/dts/mpc832x_mds.dts > delete mode 100644 arch/powerpc/boot/dts/mpc834x_mds.dts > delete mode 100644 arch/powerpc/boot/dts/mpc836x_mds.dts > delete mode 100644 arch/powerpc/boot/dts/mpc8377_mds.dts > delete mode 100644 arch/powerpc/boot/dts/mpc8378_mds.dts > delete mode 100644 arch/powerpc/boot/dts/mpc8379_mds.dts > delete mode 100644 arch/powerpc/configs/83xx/mpc832x_mds_defconfig > delete mode 100644 arch/powerpc/configs/83xx/mpc834x_mds_defconfig > delete mode 100644 arch/powerpc/configs/83xx/mpc836x_mds_defconfig > delete mode 100644 arch/powerpc/configs/83xx/mpc837x_mds_defconfig > delete mode 100644 arch/powerpc/platforms/83xx/mpc832x_mds.c > delete mode 100644 arch/powerpc/platforms/83xx/mpc834x_mds.c > delete mode 100644 arch/powerpc/platforms/83xx/mpc836x_mds.c > delete mode 100644 arch/powerpc/platforms/83xx/mpc837x_mds.c > > -- > 2.17.1
Le 20/02/2023 à 12:59, Paul Gortmaker a écrit : > [This RFC is proposed for v6.4 and hence is based off linux-next.] > > This series removes support for four e300 (MPC83xx) Freescale processor > family evaluation boards that were added to the kernel in the 2006 era. > > These boards were all of a very similar form factor, a largish PCI or PCI-X > card that could also be used standalone with an external power brick, and > all shared the Modular Development System (MDS) designation. > > These platforms were made in limited quantity and were generally designed > to get early silicon into the hands of OEMs who would later develop their > own boards/platforms. As such, availability was limited to those who would > be working on boards and/or BSP support. > > Many early revision MDS platforms used a mechanical clamping system to hold > the BGA CPU in place to facilitate CPU updates -- something not normally > possible for a soldered down BGA in a COTS system. > > The point of these details is to give context that reflects that these four > boards were made in limited quantities, were not in a form factor that is > really "hobbyist" friendly and hence make sense for removal 17 years later. > > Here, we remove the MPC8548E-MDS[1], the MPC8360E-MDS[2], the > MPC837xE-MDS[3], and the MPC832x-MDS[4] board support from the kernel. > > There will still exist several e300 Freescale Reference Design System (RDS) > boards[5] and mini-ITX boards[6] with support in the kernel. While these > were more of a COTS "ready to deploy" design more suited to hobbyists, it > probably makes sense to consider removing these as well, based on age. Those boards are still being sold, see https://www.components-store.fr/product/NXP-Semiconductors-Freescale/MPC8323E-RDB.html they have 4600 pieces in stock. Christophe
[Re: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms] On 25/02/2023 (Sat 07:40) Christophe Leroy wrote: > > > Le 20/02/2023 ?? 12:59, Paul Gortmaker a ??crit??: > > [This RFC is proposed for v6.4 and hence is based off linux-next.] > > > > This series removes support for four e300 (MPC83xx) Freescale processor > > family evaluation boards that were added to the kernel in the 2006 era. > > > > These boards were all of a very similar form factor, a largish PCI or PCI-X > > card that could also be used standalone with an external power brick, and > > all shared the Modular Development System (MDS) designation. > > > > These platforms were made in limited quantity and were generally designed > > to get early silicon into the hands of OEMs who would later develop their > > own boards/platforms. As such, availability was limited to those who would > > be working on boards and/or BSP support. > > > > Many early revision MDS platforms used a mechanical clamping system to hold > > the BGA CPU in place to facilitate CPU updates -- something not normally > > possible for a soldered down BGA in a COTS system. > > > > The point of these details is to give context that reflects that these four > > boards were made in limited quantities, were not in a form factor that is > > really "hobbyist" friendly and hence make sense for removal 17 years later. > > > > Here, we remove the MPC8548E-MDS[1], the MPC8360E-MDS[2], the > > MPC837xE-MDS[3], and the MPC832x-MDS[4] board support from the kernel. > > > > There will still exist several e300 Freescale Reference Design System (RDS) > > boards[5] and mini-ITX boards[6] with support in the kernel. While these > > were more of a COTS "ready to deploy" design more suited to hobbyists, it > > probably makes sense to consider removing these as well, based on age. > > Those boards are still being sold, see > https://www.components-store.fr/product/NXP-Semiconductors-Freescale/MPC8323E-RDB.html > they have 4600 pieces in stock. Just to clarify for others - your link is for RDB boards - which I said should be considered, but are not touched in this series. Secondly, even if there may exist a large amount of NOS (New Old Stock) of RDB boards from 15+ years ago - the reality is that they will only be used in small quantities to repair legacy STB or similar - where no hardware upgrade path exists. That corner case will happen w/o changing firmware or software (i.e. u-boot or kernel). I can assure you that no sane company is going to take a 2006 STB/PVR and do a software update to a 6.4 kernel. That would go against decades of Product Life Cycle experience, and would be inviting disaster as you go up the wrong side of the bathtub curve. As for hobbyists - feel free to go ahead and e-mail the folks at your components-store link and ask for a quote, since they don't list a price. When you get an answer of $800-$2000 USD - tell me who is going buy one vs. a modern PC. Oh, and ask if they have next day shipping, since they claim to have 4600 in stock - which also seems very suspect, or a horribly bad investment on their part. Don't get me wrong - I appreciate the input, but I don't think it really alters what the right thing to do is for the 6.4+ kernel. Thanks, Paul. -- > > Christophe
[RE: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms] On 24/02/2023 (Fri 21:16) Leo Li wrote: > > > > -----Original Message----- > > From: Paul Gortmaker <paul.gortmaker@windriver.com> > > Sent: Monday, February 20, 2023 5:59 AM > > To: linuxppc-dev@lists.ozlabs.org > > Cc: Leo Li <leoyang.li@nxp.com>; Claudiu Manoil <claudiu.manoil@nxp.com>; > > Paul Gortmaker <paul.gortmaker@windriver.com>; Scott Wood > > <oss@buserror.net>; Michael Ellerman <mpe@ellerman.id.au>; Benjamin > > Herrenschmidt <benh@kernel.crashing.org>; Paul Mackerras > > <paulus@samba.org> > > Subject: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms > > > > [This RFC is proposed for v6.4 and hence is based off linux-next.] > > > > This series removes support for four e300 (MPC83xx) Freescale processor > > family evaluation boards that were added to the kernel in the 2006 era. > > Hi Paul, > > I talked with our marketing team on this. Although we do not recommend any new design with these SoCs, they are still being shipped in large amount to customers now. Plus it is possible for the bigger amount of existing devices to be updating their software that includes a new kernel. So we should definitely keep all the common SoC code that might be needed to support their own design. Thanks for confirming with your marketing team that they "do not recommend any new design with these SoCs" -- it also confirms the information I read on the web pages for the platforms. As those of us immersed in this world all know from the 101 basics of Product Life Cycle lessons, it doesn't matter if it is a phone or a set-top-box/PVR or whatever else kind of non-PC consumer device -- kernel uprevs never happen in that product space. So with the best interests of the mainline kernel in mind, I think we are good to proceed with this for summer 2023. And of course as I've said many times before - the kernel is in git, so really you can't delete anything anyway - it remains in history forever. Thanks, Paul. -- > > > > > These boards were all of a very similar form factor, a largish PCI or PCI-X card > > that could also be used standalone with an external power brick, and all > > shared the Modular Development System (MDS) designation. > > > > These platforms were made in limited quantity and were generally designed > > to get early silicon into the hands of OEMs who would later develop their > > own boards/platforms. As such, availability was limited to those who would > > be working on boards and/or BSP support. > > > > Many early revision MDS platforms used a mechanical clamping system to > > hold the BGA CPU in place to facilitate CPU updates -- something not > > normally possible for a soldered down BGA in a COTS system. > > > > The point of these details is to give context that reflects that these four > > boards were made in limited quantities, were not in a form factor that is > > really "hobbyist" friendly and hence make sense for removal 17 years later. > > We would agree with you that the MDS platforms are only used by a limited number of customers for evaluation purpose, so it should be fine to be removed. So for this series: > > Acked-by: Li Yang <leoyang.li@nxp.com> > > > > > Here, we remove the MPC8548E-MDS[1], the MPC8360E-MDS[2], the > > MPC837xE-MDS[3], and the MPC832x-MDS[4] board support from the kernel. > > > > There will still exist several e300 Freescale Reference Design System (RDS) > > boards[5] and mini-ITX boards[6] with support in the kernel. While these > > were more of a COTS "ready to deploy" design more suited to hobbyists, it > > probably makes sense to consider removing these as well, based on age. > > These boards are mass market boards that sold in larger amount and are much more likely to still be used. We would suggest we keep them for now. > > > > > But before we get to that, lets see how this goes -- and then we should look > > at similar early e500 evaluation platforms [MPC8540-ADS, etc] next, as the > > oldest there date back to 2002[7] -- before considering RDB/mITX. > > > > I intentionally didn't put any links in the commits, since as we all know, they > > tend not to be stable long term, so keep them here in the merge data. > > Credit to NXP for keeping around these old legacy docs this long! > > > > Paul. > > > > -- > > > > [1] > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > .nxp.com%2Fdesign%2Fqoriq-developer-resources%2Fmpc8349e-modular- > > development- > > system%3AMPC8349EMDS&data=05%7C01%7Cleoyang.li%40nxp.com%7Ca2 > > 820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301635% > > 7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 > > 0%7C%7C%7C&sdata=Q4COgwpjsE4mHXvl9HdGo3otPCYML3z%2FR6IoCEYRE > > wg%3D&reserved=0 > > [2] > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > .nxp.com%2Fdocs%2Fen%2Fuser- > > guide%2FMPC8360EMDSUM.pdf&data=05%7C01%7Cleoyang.li%40nxp.com > > %7Ca2820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c30 > > 1635%7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8ey > > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% > > 7C3000%7C%7C%7C&sdata=JyLT0MfGAHQ8a%2FNgpLdVFtyACkwPR%2FOkB > > yN1aW0wySs%3D&reserved=0 > > [3] > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > .nxp.com%2Fproducts%2Fprocessors-and-microcontrollers%2Flegacy-mpu- > > mcus%2Fpowerquicc-processors%2Fpowerquicc-iii-mpc85xx%2Fmpc837xe- > > modular-development- > > system%3AMPC837XEMDS&data=05%7C01%7Cleoyang.li%40nxp.com%7Ca2 > > 820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301635% > > 7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 > > 0%7C%7C%7C&sdata=052dpEEcGmbuhRLnMDCNoOkTeguF%2BPA0oJGNvV1 > > jSjI%3D&reserved=0 > > [4] > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > .nxp.com%2Fproducts%2Fprocessors-and-microcontrollers%2Flegacy-mpu- > > mcus%2Fpowerquicc-processors%2Fpowerquicc-ii-pro-mpc83xx%2Flow- > > power-powerquicc-ii-pro-processor-with-ddr2-tdm-pci-security-usb-quicc- > > engine-with- > > utopia%3AMPC8323E&data=05%7C01%7Cleoyang.li%40nxp.com%7Ca2820c1 > > e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0% > > 7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7 > > C%7C%7C&sdata=mZQh%2FogNgNUb0wNJV972kYIDvn61gx0TWNd1u1d7PZ > > Q%3D&reserved=0 > > [5] > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > .nxp.com%2Fdocs%2Fen%2Ffact- > > sheet%2FMPC8379ERDBFS.pdf&data=05%7C01%7Cleoyang.li%40nxp.com%7 > > Ca2820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c3016 > > 35%7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJ > > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% > > 7C3000%7C%7C%7C&sdata=EJmP6Regr7zpvYvHUmX64h3LZSaBT3Mb1h%2BN > > KQT%2FUls%3D&reserved=0 > > [6] > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > .digikey.ca%2Fen%2Fproducts%2Fdetail%2Fnxp-usa-inc%2FMPC8349E-MITX- > > GP%2F1204733&data=05%7C01%7Cleoyang.li%40nxp.com%7Ca2820c1e44264 > > 0c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7 > > C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw > > MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C% > > 7C&sdata=hw6IQDUaXH6huQFCnCkFIbNfj1xMrq%2FanDMUU%2FXZYQg%3 > > D&reserved=0 > > [7] > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > .nxp.com%2Fdocs%2Fen%2Freference- > > manual%2FMPC8560ADSUG.pdf&data=05%7C01%7Cleoyang.li%40nxp.com% > > 7Ca2820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301 > > 635%7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJ > > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% > > 7C3000%7C%7C%7C&sdata=Ed%2BZR07y9Sp8xx5H47SAXzk9ET73creygxk%2B > > emmbfuA%3D&reserved=0 > > > > Cc: Scott Wood <oss@buserror.net> > > Cc: Michael Ellerman <mpe@ellerman.id.au> > > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> > > Cc: Paul Mackerras <paulus@samba.org> > > Cc: Li Yang <leoyang.li@nxp.com> > > Cc: Claudiu Manoil <claudiu.manoil@nxp.com> > > > > --- > > > > Paul Gortmaker (4): > > powerpc: drop MPC834x_MDS platform support > > powerpc: drop MPC836x_MDS platform support > > powerpc: drop MPC837x_MDS platform support > > powerpc: drop MPC832x_MDS platform support > > > > arch/powerpc/boot/Makefile | 1 - > > arch/powerpc/boot/dts/mpc832x_mds.dts | 436 --------------- > > arch/powerpc/boot/dts/mpc834x_mds.dts | 403 -------------- > > arch/powerpc/boot/dts/mpc836x_mds.dts | 481 ----------------- > > arch/powerpc/boot/dts/mpc8377_mds.dts | 505 ------------------ > > arch/powerpc/boot/dts/mpc8378_mds.dts | 489 ----------------- > > arch/powerpc/boot/dts/mpc8379_mds.dts | 455 ---------------- > > .../configs/83xx/mpc832x_mds_defconfig | 59 -- > > .../configs/83xx/mpc834x_mds_defconfig | 58 -- > > .../configs/83xx/mpc836x_mds_defconfig | 64 --- > > .../configs/83xx/mpc837x_mds_defconfig | 58 -- > > arch/powerpc/configs/mpc83xx_defconfig | 4 - > > arch/powerpc/configs/ppc6xx_defconfig | 4 - > > arch/powerpc/platforms/83xx/Kconfig | 32 -- > > arch/powerpc/platforms/83xx/Makefile | 4 - > > arch/powerpc/platforms/83xx/mpc832x_mds.c | 110 ---- > > arch/powerpc/platforms/83xx/mpc834x_mds.c | 101 ---- > > arch/powerpc/platforms/83xx/mpc836x_mds.c | 210 -------- > > arch/powerpc/platforms/83xx/mpc837x_mds.c | 103 ---- > > 19 files changed, 3577 deletions(-) > > delete mode 100644 arch/powerpc/boot/dts/mpc832x_mds.dts > > delete mode 100644 arch/powerpc/boot/dts/mpc834x_mds.dts > > delete mode 100644 arch/powerpc/boot/dts/mpc836x_mds.dts > > delete mode 100644 arch/powerpc/boot/dts/mpc8377_mds.dts > > delete mode 100644 arch/powerpc/boot/dts/mpc8378_mds.dts > > delete mode 100644 arch/powerpc/boot/dts/mpc8379_mds.dts > > delete mode 100644 arch/powerpc/configs/83xx/mpc832x_mds_defconfig > > delete mode 100644 arch/powerpc/configs/83xx/mpc834x_mds_defconfig > > delete mode 100644 arch/powerpc/configs/83xx/mpc836x_mds_defconfig > > delete mode 100644 arch/powerpc/configs/83xx/mpc837x_mds_defconfig > > delete mode 100644 arch/powerpc/platforms/83xx/mpc832x_mds.c > > delete mode 100644 arch/powerpc/platforms/83xx/mpc834x_mds.c > > delete mode 100644 arch/powerpc/platforms/83xx/mpc836x_mds.c > > delete mode 100644 arch/powerpc/platforms/83xx/mpc837x_mds.c > > > > -- > > 2.17.1 >
On Sat, Feb 25, 2023, at 17:50, Paul Gortmaker wrote: > [RE: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms] On > 24/02/2023 (Fri 21:16) Leo Li wrote: > > Thanks for confirming with your marketing team that they "do not > recommend any new design with these SoCs" -- it also confirms the > information I read on the web pages for the platforms. > > As those of us immersed in this world all know from the 101 basics of > Product Life Cycle lessons, it doesn't matter if it is a phone or a > set-top-box/PVR or whatever else kind of non-PC consumer device -- > kernel uprevs never happen in that product space. > > So with the best interests of the mainline kernel in mind, I think we > are good to proceed with this for summer 2023. And of course as I've > said many times before - the kernel is in git, so really you can't > delete anything anyway - it remains in history forever. Thanks for working on this, this is a good step towards removing the known unused code. One aspect I'd add from doing similar cleanups on arm32 is that I would prioritize removing evaluation platforms for SoCs that have no other supported boards, and then garbage-collecting the device drivers that become unused. I'm not sure where the RDB boards fit in that, in particular if an unmodified kernel would work on a machine that is derived from the reference platform, or if it really only works on the machine itself. On most arm platforms, we moved to having only per-soc "compatible" strings, but on Freescale ppc32 it appears that the kernel always matches a board specific string and requires patches in order to support anything else. Arnd
On Sat, Feb 25, 2023 at 4:51 PM Arnd Bergmann <arnd@arndb.de> wrote: > > On Sat, Feb 25, 2023, at 17:50, Paul Gortmaker wrote: > > [RE: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms] On > > 24/02/2023 (Fri 21:16) Leo Li wrote: > > > > Thanks for confirming with your marketing team that they "do not > > recommend any new design with these SoCs" -- it also confirms the > > information I read on the web pages for the platforms. > > > > As those of us immersed in this world all know from the 101 basics of > > Product Life Cycle lessons, it doesn't matter if it is a phone or a > > set-top-box/PVR or whatever else kind of non-PC consumer device -- > > kernel uprevs never happen in that product space. > > > > So with the best interests of the mainline kernel in mind, I think we > > are good to proceed with this for summer 2023. And of course as I've > > said many times before - the kernel is in git, so really you can't > > delete anything anyway - it remains in history forever. > > Thanks for working on this, this is a good step towards removing > the known unused code. One aspect I'd add from doing similar cleanups > on arm32 is that I would prioritize removing evaluation platforms > for SoCs that have no other supported boards, and then > garbage-collecting the device drivers that become unused. > > I'm not sure where the RDB boards fit in that, in particular if > an unmodified kernel would work on a machine that is derived from > the reference platform, or if it really only works on the machine > itself. On most arm platforms, we moved to having only per-soc > "compatible" strings, but on Freescale ppc32 it appears that > the kernel always matches a board specific string and requires > patches in order to support anything else. The RDB boards normally don't include the complex configuration mechanisms as used on the MDS platforms to support different configurations at the same time. They were designed to mimic a real product and should be much more likely to work unmodified or with some minor tweaks. Regards, Leo
On Sat, Feb 25, 2023 at 10:52 AM Paul Gortmaker <paul.gortmaker@windriver.com> wrote: > > [RE: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms] On 24/02/2023 (Fri 21:16) Leo Li wrote: > > > > > > > > -----Original Message----- > > > From: Paul Gortmaker <paul.gortmaker@windriver.com> > > > Sent: Monday, February 20, 2023 5:59 AM > > > To: linuxppc-dev@lists.ozlabs.org > > > Cc: Leo Li <leoyang.li@nxp.com>; Claudiu Manoil <claudiu.manoil@nxp.com>; > > > Paul Gortmaker <paul.gortmaker@windriver.com>; Scott Wood > > > <oss@buserror.net>; Michael Ellerman <mpe@ellerman.id.au>; Benjamin > > > Herrenschmidt <benh@kernel.crashing.org>; Paul Mackerras > > > <paulus@samba.org> > > > Subject: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms > > > > > > [This RFC is proposed for v6.4 and hence is based off linux-next.] > > > > > > This series removes support for four e300 (MPC83xx) Freescale processor > > > family evaluation boards that were added to the kernel in the 2006 era. > > > > Hi Paul, > > > > I talked with our marketing team on this. Although we do not recommend any new design with these SoCs, they are still being shipped in large amount to customers now. Plus it is possible for the bigger amount of existing devices to be updating their software that includes a new kernel. So we should definitely keep all the common SoC code that might be needed to support their own design. > > Thanks for confirming with your marketing team that they "do not > recommend any new design with these SoCs" -- it also confirms the > information I read on the web pages for the platforms. > > As those of us immersed in this world all know from the 101 basics of > Product Life Cycle lessons, it doesn't matter if it is a phone or a > set-top-box/PVR or whatever else kind of non-PC consumer device -- > kernel uprevs never happen in that product space. One thing is that the QorIQ platforms are not for the consumer devices. They are mostly used in networking or communication equipment. I think their product life cycle would be more like the server or data center scenario. Regards, Leo > > So with the best interests of the mainline kernel in mind, I think we > are good to proceed with this for summer 2023. And of course as I've > said many times before - the kernel is in git, so really you can't > delete anything anyway - it remains in history forever. > > Thanks, > Paul. > -- > > > > > > > > > These boards were all of a very similar form factor, a largish PCI or PCI-X card > > > that could also be used standalone with an external power brick, and all > > > shared the Modular Development System (MDS) designation. > > > > > > These platforms were made in limited quantity and were generally designed > > > to get early silicon into the hands of OEMs who would later develop their > > > own boards/platforms. As such, availability was limited to those who would > > > be working on boards and/or BSP support. > > > > > > Many early revision MDS platforms used a mechanical clamping system to > > > hold the BGA CPU in place to facilitate CPU updates -- something not > > > normally possible for a soldered down BGA in a COTS system. > > > > > > The point of these details is to give context that reflects that these four > > > boards were made in limited quantities, were not in a form factor that is > > > really "hobbyist" friendly and hence make sense for removal 17 years later. > > > > We would agree with you that the MDS platforms are only used by a limited number of customers for evaluation purpose, so it should be fine to be removed. So for this series: > > > > Acked-by: Li Yang <leoyang.li@nxp.com> > > > > > > > > Here, we remove the MPC8548E-MDS[1], the MPC8360E-MDS[2], the > > > MPC837xE-MDS[3], and the MPC832x-MDS[4] board support from the kernel. > > > > > > There will still exist several e300 Freescale Reference Design System (RDS) > > > boards[5] and mini-ITX boards[6] with support in the kernel. While these > > > were more of a COTS "ready to deploy" design more suited to hobbyists, it > > > probably makes sense to consider removing these as well, based on age. > > > > These boards are mass market boards that sold in larger amount and are much more likely to still be used. We would suggest we keep them for now. > > > > > > > > But before we get to that, lets see how this goes -- and then we should look > > > at similar early e500 evaluation platforms [MPC8540-ADS, etc] next, as the > > > oldest there date back to 2002[7] -- before considering RDB/mITX. > > > > > > I intentionally didn't put any links in the commits, since as we all know, they > > > tend not to be stable long term, so keep them here in the merge data. > > > Credit to NXP for keeping around these old legacy docs this long! > > > > > > Paul. > > > > > > -- > > > > > > [1] > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > > .nxp.com%2Fdesign%2Fqoriq-developer-resources%2Fmpc8349e-modular- > > > development- > > > system%3AMPC8349EMDS&data=05%7C01%7Cleoyang.li%40nxp.com%7Ca2 > > > 820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301635% > > > 7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > > > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 > > > 0%7C%7C%7C&sdata=Q4COgwpjsE4mHXvl9HdGo3otPCYML3z%2FR6IoCEYRE > > > wg%3D&reserved=0 > > > [2] > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > > .nxp.com%2Fdocs%2Fen%2Fuser- > > > guide%2FMPC8360EMDSUM.pdf&data=05%7C01%7Cleoyang.li%40nxp.com > > > %7Ca2820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c30 > > > 1635%7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8ey > > > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% > > > 7C3000%7C%7C%7C&sdata=JyLT0MfGAHQ8a%2FNgpLdVFtyACkwPR%2FOkB > > > yN1aW0wySs%3D&reserved=0 > > > [3] > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > > .nxp.com%2Fproducts%2Fprocessors-and-microcontrollers%2Flegacy-mpu- > > > mcus%2Fpowerquicc-processors%2Fpowerquicc-iii-mpc85xx%2Fmpc837xe- > > > modular-development- > > > system%3AMPC837XEMDS&data=05%7C01%7Cleoyang.li%40nxp.com%7Ca2 > > > 820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301635% > > > 7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > > > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 > > > 0%7C%7C%7C&sdata=052dpEEcGmbuhRLnMDCNoOkTeguF%2BPA0oJGNvV1 > > > jSjI%3D&reserved=0 > > > [4] > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > > .nxp.com%2Fproducts%2Fprocessors-and-microcontrollers%2Flegacy-mpu- > > > mcus%2Fpowerquicc-processors%2Fpowerquicc-ii-pro-mpc83xx%2Flow- > > > power-powerquicc-ii-pro-processor-with-ddr2-tdm-pci-security-usb-quicc- > > > engine-with- > > > utopia%3AMPC8323E&data=05%7C01%7Cleoyang.li%40nxp.com%7Ca2820c1 > > > e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0% > > > 7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > > > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7 > > > C%7C%7C&sdata=mZQh%2FogNgNUb0wNJV972kYIDvn61gx0TWNd1u1d7PZ > > > Q%3D&reserved=0 > > > [5] > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > > .nxp.com%2Fdocs%2Fen%2Ffact- > > > sheet%2FMPC8379ERDBFS.pdf&data=05%7C01%7Cleoyang.li%40nxp.com%7 > > > Ca2820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c3016 > > > 35%7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJ > > > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% > > > 7C3000%7C%7C%7C&sdata=EJmP6Regr7zpvYvHUmX64h3LZSaBT3Mb1h%2BN > > > KQT%2FUls%3D&reserved=0 > > > [6] > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > > .digikey.ca%2Fen%2Fproducts%2Fdetail%2Fnxp-usa-inc%2FMPC8349E-MITX- > > > GP%2F1204733&data=05%7C01%7Cleoyang.li%40nxp.com%7Ca2820c1e44264 > > > 0c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7 > > > C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw > > > MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C% > > > 7C&sdata=hw6IQDUaXH6huQFCnCkFIbNfj1xMrq%2FanDMUU%2FXZYQg%3 > > > D&reserved=0 > > > [7] > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > > .nxp.com%2Fdocs%2Fen%2Freference- > > > manual%2FMPC8560ADSUG.pdf&data=05%7C01%7Cleoyang.li%40nxp.com% > > > 7Ca2820c1e442640c5a39108db1339fd9f%7C686ea1d3bc2b4c6fa92cd99c5c301 > > > 635%7C0%7C1%7C638124912025220501%7CUnknown%7CTWFpbGZsb3d8eyJ > > > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% > > > 7C3000%7C%7C%7C&sdata=Ed%2BZR07y9Sp8xx5H47SAXzk9ET73creygxk%2B > > > emmbfuA%3D&reserved=0 > > > > > > Cc: Scott Wood <oss@buserror.net> > > > Cc: Michael Ellerman <mpe@ellerman.id.au> > > > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> > > > Cc: Paul Mackerras <paulus@samba.org> > > > Cc: Li Yang <leoyang.li@nxp.com> > > > Cc: Claudiu Manoil <claudiu.manoil@nxp.com> > > > > > > --- > > > > > > Paul Gortmaker (4): > > > powerpc: drop MPC834x_MDS platform support > > > powerpc: drop MPC836x_MDS platform support > > > powerpc: drop MPC837x_MDS platform support > > > powerpc: drop MPC832x_MDS platform support > > > > > > arch/powerpc/boot/Makefile | 1 - > > > arch/powerpc/boot/dts/mpc832x_mds.dts | 436 --------------- > > > arch/powerpc/boot/dts/mpc834x_mds.dts | 403 -------------- > > > arch/powerpc/boot/dts/mpc836x_mds.dts | 481 ----------------- > > > arch/powerpc/boot/dts/mpc8377_mds.dts | 505 ------------------ > > > arch/powerpc/boot/dts/mpc8378_mds.dts | 489 ----------------- > > > arch/powerpc/boot/dts/mpc8379_mds.dts | 455 ---------------- > > > .../configs/83xx/mpc832x_mds_defconfig | 59 -- > > > .../configs/83xx/mpc834x_mds_defconfig | 58 -- > > > .../configs/83xx/mpc836x_mds_defconfig | 64 --- > > > .../configs/83xx/mpc837x_mds_defconfig | 58 -- > > > arch/powerpc/configs/mpc83xx_defconfig | 4 - > > > arch/powerpc/configs/ppc6xx_defconfig | 4 - > > > arch/powerpc/platforms/83xx/Kconfig | 32 -- > > > arch/powerpc/platforms/83xx/Makefile | 4 - > > > arch/powerpc/platforms/83xx/mpc832x_mds.c | 110 ---- > > > arch/powerpc/platforms/83xx/mpc834x_mds.c | 101 ---- > > > arch/powerpc/platforms/83xx/mpc836x_mds.c | 210 -------- > > > arch/powerpc/platforms/83xx/mpc837x_mds.c | 103 ---- > > > 19 files changed, 3577 deletions(-) > > > delete mode 100644 arch/powerpc/boot/dts/mpc832x_mds.dts > > > delete mode 100644 arch/powerpc/boot/dts/mpc834x_mds.dts > > > delete mode 100644 arch/powerpc/boot/dts/mpc836x_mds.dts > > > delete mode 100644 arch/powerpc/boot/dts/mpc8377_mds.dts > > > delete mode 100644 arch/powerpc/boot/dts/mpc8378_mds.dts > > > delete mode 100644 arch/powerpc/boot/dts/mpc8379_mds.dts > > > delete mode 100644 arch/powerpc/configs/83xx/mpc832x_mds_defconfig > > > delete mode 100644 arch/powerpc/configs/83xx/mpc834x_mds_defconfig > > > delete mode 100644 arch/powerpc/configs/83xx/mpc836x_mds_defconfig > > > delete mode 100644 arch/powerpc/configs/83xx/mpc837x_mds_defconfig > > > delete mode 100644 arch/powerpc/platforms/83xx/mpc832x_mds.c > > > delete mode 100644 arch/powerpc/platforms/83xx/mpc834x_mds.c > > > delete mode 100644 arch/powerpc/platforms/83xx/mpc836x_mds.c > > > delete mode 100644 arch/powerpc/platforms/83xx/mpc837x_mds.c > > > > > > -- > > > 2.17.1 > >
On Mon, 2023-02-27 at 14:48 -0600, Li Yang wrote: > On Sat, Feb 25, 2023 at 10:52 AM Paul Gortmaker > <paul.gortmaker@windriver.com> wrote: > > > > [RE: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms] On 24/02/2023 (Fri 21:16) Leo Li wrote: > > > > > > > > > > > > -----Original Message----- > > > > From: Paul Gortmaker <paul.gortmaker@windriver.com> > > > > Sent: Monday, February 20, 2023 5:59 AM > > > > To: linuxppc-dev@lists.ozlabs.org > > > > Cc: Leo Li <leoyang.li@nxp.com>; Claudiu Manoil <claudiu.manoil@nxp.com>; > > > > Paul Gortmaker <paul.gortmaker@windriver.com>; Scott Wood > > > > <oss@buserror.net>; Michael Ellerman <mpe@ellerman.id.au>; Benjamin > > > > Herrenschmidt <benh@kernel.crashing.org>; Paul Mackerras > > > > <paulus@samba.org> > > > > Subject: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms > > > > > > > > [This RFC is proposed for v6.4 and hence is based off linux-next.] > > > > > > > > This series removes support for four e300 (MPC83xx) Freescale processor > > > > family evaluation boards that were added to the kernel in the 2006 era. > > > > > > Hi Paul, > > > > > > I talked with our marketing team on this. Although we do not recommend any new design with these SoCs, they are still being shipped in large amount to customers now. Plus it is possible for the bigger amount of existing devices to be updating their software that includes a new kernel. So we should definitely keep all the common SoC code that might be needed to support their own design. > > > > Thanks for confirming with your marketing team that they "do not > > recommend any new design with these SoCs" -- it also confirms the > > information I read on the web pages for the platforms. > > > > As those of us immersed in this world all know from the 101 basics of > > Product Life Cycle lessons, it doesn't matter if it is a phone or a > > set-top-box/PVR or whatever else kind of non-PC consumer device -- > > kernel uprevs never happen in that product space. > > One thing is that the QorIQ platforms are not for the consumer > devices. They are mostly used in networking or communication > equipment. I think their product life cycle would be more like the > server or data center scenario. > > Regards, > Leo > > > > So with the best interests of the mainline kernel in mind, I think we > > are good to proceed with this for summer 2023. And of course as I've > > said many times before - the kernel is in git, so really you can't > > delete anything anyway - it remains in history forever. > > > > Thanks, > > Paul. > > -- > > > > > > > > > > > > > These boards were all of a very similar form factor, a largish PCI or PCI-X card > > > > that could also be used standalone with an external power brick, and all > > > > shared the Modular Development System (MDS) designation. > > > > > > > > These platforms were made in limited quantity and were generally designed > > > > to get early silicon into the hands of OEMs who would later develop their > > > > own boards/platforms. As such, availability was limited to those who would > > > > be working on boards and/or BSP support. > > > > > > > > Many early revision MDS platforms used a mechanical clamping system to > > > > hold the BGA CPU in place to facilitate CPU updates -- something not > > > > normally possible for a soldered down BGA in a COTS system. > > > > > > > > The point of these details is to give context that reflects that these four > > > > boards were made in limited quantities, were not in a form factor that is > > > > really "hobbyist" friendly and hence make sense for removal 17 years later. > > > > > > We would agree with you that the MDS platforms are only used by a limited number of customers for evaluation purpose, so it should be fine to be removed. So for this series: > > > > > > Acked-by: Li Yang <leoyang.li@nxp.com> > > > > > > > > > > > Here, we remove the MPC8548E-MDS[1], the MPC8360E-MDS[2], the > > > > MPC837xE-MDS[3], and the MPC832x-MDS[4] board support from the kernel. > > > > > > > > There will still exist several e300 Freescale Reference Design System (RDS) > > > > boards[5] and mini-ITX boards[6] with support in the kernel. While these > > > > were more of a COTS "ready to deploy" design more suited to hobbyists, it > > > > probably makes sense to consider removing these as well, based on age. > > > > > > These boards are mass market boards that sold in larger amount and are much more likely to still be used. We would suggest we keep them for now. Agreed, the RDS design is still used here. > >
On Tue, Feb 28, 2023, at 11:03, Joakim Tjernlund wrote: > On Mon, 2023-02-27 at 14:48 -0600, Li Yang wrote: >> > > > >> > > > Here, we remove the MPC8548E-MDS[1], the MPC8360E-MDS[2], the >> > > > MPC837xE-MDS[3], and the MPC832x-MDS[4] board support from the kernel. >> > > > >> > > > There will still exist several e300 Freescale Reference Design System (RDS) >> > > > boards[5] and mini-ITX boards[6] with support in the kernel. While these >> > > > were more of a COTS "ready to deploy" design more suited to hobbyists, it >> > > > probably makes sense to consider removing these as well, based on age. >> > > >> > > These boards are mass market boards that sold in larger amount and are much more likely to still be used. We would suggest we keep them for now. > > Agreed, the RDS design is still used here. Can you elaborate what the typical kernel upgrade schedule for these boards? Note that for the debate about dropping the machines from future kernels, it does not really matter how many remaining users there are or how many boards get sold. The only question is whether someone is still planning to provide upgrades to kernels later than linux-6.3 in the future. It sounds like there are commercial requirements for validating and distributing kernel upgrades (in addition to hobbyist uses), so I would expect that whoever is paying for the upgrades has a clear plan for how much longer they are going to do that, or at least a some idea of how many of the previous LTS kernels (5.10, 5.15, 6.1) ended up actually getting shipped to users. It may be worth pointing out that the official webpage for the MPC8313ERDB board in the example only lists a hilariously outdated BSP kernel based on a patched linux-2.6.23 release, so maybe the marketing team can change that to point to the latest validated LTS kernel instead. Arnd
On Tue, Feb 28, 2023 at 11:52 AM Arnd Bergmann <arnd@arndb.de> wrote: > > On Tue, Feb 28, 2023, at 11:03, Joakim Tjernlund wrote: > > On Mon, 2023-02-27 at 14:48 -0600, Li Yang wrote: > >> > > > > >> > > > Here, we remove the MPC8548E-MDS[1], the MPC8360E-MDS[2], the > >> > > > MPC837xE-MDS[3], and the MPC832x-MDS[4] board support from the kernel. > >> > > > > >> > > > There will still exist several e300 Freescale Reference Design System (RDS) > >> > > > boards[5] and mini-ITX boards[6] with support in the kernel. While these > >> > > > were more of a COTS "ready to deploy" design more suited to hobbyists, it > >> > > > probably makes sense to consider removing these as well, based on age. > >> > > > >> > > These boards are mass market boards that sold in larger amount and are much more likely to still be used. We would suggest we keep them for now. > > > > Agreed, the RDS design is still used here. > > Can you elaborate what the typical kernel upgrade schedule for > these boards? > > Note that for the debate about dropping the machines from future > kernels, it does not really matter how many remaining users there > are or how many boards get sold. The only question is whether > someone is still planning to provide upgrades to kernels later > than linux-6.3 in the future. > > It sounds like there are commercial requirements for validating > and distributing kernel upgrades (in addition to hobbyist uses), so > I would expect that whoever is paying for the upgrades has a clear > plan for how much longer they are going to do that, or at least > a some idea of how many of the previous LTS kernels (5.10, 5.15, > 6.1) ended up actually getting shipped to users. > > It may be worth pointing out that the official webpage for > the MPC8313ERDB board in the example only lists a hilariously > outdated BSP kernel based on a patched linux-2.6.23 release, > so maybe the marketing team can change that to point to the > latest validated LTS kernel instead. The BSP/SDK releases from NXP do follow a different development principle from working with upstream directly. However, we do value the customers who prefer to work closer with the upstream community than relying on our BSPs/SDKs deliveries and that's why we pushed our development team internally to upstream code as much as possible. And we will try to help keep them well maintained in the community. Regards, Leo
Le 28/02/2023 à 18:51, Arnd Bergmann a écrit : > On Tue, Feb 28, 2023, at 11:03, Joakim Tjernlund wrote: >> On Mon, 2023-02-27 at 14:48 -0600, Li Yang wrote: >>>>>> >>>>>> Here, we remove the MPC8548E-MDS[1], the MPC8360E-MDS[2], the >>>>>> MPC837xE-MDS[3], and the MPC832x-MDS[4] board support from the kernel. >>>>>> >>>>>> There will still exist several e300 Freescale Reference Design System (RDS) >>>>>> boards[5] and mini-ITX boards[6] with support in the kernel. While these >>>>>> were more of a COTS "ready to deploy" design more suited to hobbyists, it >>>>>> probably makes sense to consider removing these as well, based on age. >>>>> >>>>> These boards are mass market boards that sold in larger amount and are much more likely to still be used. We would suggest we keep them for now. >> >> Agreed, the RDS design is still used here. > > Can you elaborate what the typical kernel upgrade schedule for > these boards? > > Note that for the debate about dropping the machines from future > kernels, it does not really matter how many remaining users there > are or how many boards get sold. The only question is whether > someone is still planning to provide upgrades to kernels later > than linux-6.3 in the future. > > It sounds like there are commercial requirements for validating > and distributing kernel upgrades (in addition to hobbyist uses), so > I would expect that whoever is paying for the upgrades has a clear > plan for how much longer they are going to do that, or at least > a some idea of how many of the previous LTS kernels (5.10, 5.15, > 6.1) ended up actually getting shipped to users. > > It may be worth pointing out that the official webpage for > the MPC8313ERDB board in the example only lists a hilariously > outdated BSP kernel based on a patched linux-2.6.23 release, > so maybe the marketing team can change that to point to the > latest validated LTS kernel instead. Let me present things in a slightly different way. My company has designed and manufactured and sold communication systems embedding three types of boards: - First generation, with MPC 866, designed around 2002. - Second generation, with MPC 885, designed around 2010. - Third generation, with MPC 8321, designed around 2014. When NXP announced end of life of MPC 866 and 885, we bought enough CPUs to be able to produce boards for the 10 following years so we still produce some. MPC 8321 is still in production. All those boards are used in critical systems where we have a customer requirement to keep all software including U-boot and Linux kernel up to date, for IT security reason mainly. Until now, the boards were delivered with kernel 4.14, with is due to EOL early next year. At the moment we are working on upgrading to mainline kernel with the target being to be able to upgrade our customers to next LTS kernel at the begining of 2024. Note that because our kernel code is prehistoric, it is not mergeable to mainline. Not because of licence issues but because the code is just not following at all linux standard. So our boards are not in mainline. Two of them are in U-boot and the third one should soon be as well. So, to come back about the RDB boards, we have a couple of MPC 885 ADS and a couple of MPC 8321 RDB. They are reference boards and we always check that a given kernel version properly runs on them before starting to port it to our hardware. Hope it clarifies how those reference boards are used. Christophe
On Wed, Mar 1, 2023, at 15:23, Christophe Leroy wrote: > So, to come back about the RDB boards, we have a couple of MPC 885 ADS > and a couple of MPC 8321 RDB. They are reference boards and we always > check that a given kernel version properly runs on them before starting > to port it to our hardware. > > Hope it clarifies how those reference boards are used. Indeed it does, thanks a lot for the clarification! Arnd
[Re: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms] On 01/03/2023 (Wed 14:23) Christophe Leroy wrote: > > > Le 28/02/2023 ?? 18:51, Arnd Bergmann a ??crit??: > > On Tue, Feb 28, 2023, at 11:03, Joakim Tjernlund wrote: > >> On Mon, 2023-02-27 at 14:48 -0600, Li Yang wrote: > >>>>>> > >>>>>> Here, we remove the MPC8548E-MDS[1], the MPC8360E-MDS[2], the > >>>>>> MPC837xE-MDS[3], and the MPC832x-MDS[4] board support from the kernel. > >>>>>> > >>>>>> There will still exist several e300 Freescale Reference Design System (RDS) > >>>>>> boards[5] and mini-ITX boards[6] with support in the kernel. While these > >>>>>> were more of a COTS "ready to deploy" design more suited to hobbyists, it > >>>>>> probably makes sense to consider removing these as well, based on age. > >>>>> > >>>>> These boards are mass market boards that sold in larger amount and are much more likely to still be used. We would suggest we keep them for now. > >> > >> Agreed, the RDS design is still used here. > > > > Can you elaborate what the typical kernel upgrade schedule for > > these boards? > > > > Note that for the debate about dropping the machines from future > > kernels, it does not really matter how many remaining users there > > are or how many boards get sold. The only question is whether > > someone is still planning to provide upgrades to kernels later > > than linux-6.3 in the future. > > > > It sounds like there are commercial requirements for validating > > and distributing kernel upgrades (in addition to hobbyist uses), so > > I would expect that whoever is paying for the upgrades has a clear > > plan for how much longer they are going to do that, or at least > > a some idea of how many of the previous LTS kernels (5.10, 5.15, > > 6.1) ended up actually getting shipped to users. > > > > It may be worth pointing out that the official webpage for > > the MPC8313ERDB board in the example only lists a hilariously > > outdated BSP kernel based on a patched linux-2.6.23 release, > > so maybe the marketing team can change that to point to the > > latest validated LTS kernel instead. > > Let me present things in a slightly different way. > > My company has designed and manufactured and sold communication systems > embedding three types of boards: > - First generation, with MPC 866, designed around 2002. > - Second generation, with MPC 885, designed around 2010. > - Third generation, with MPC 8321, designed around 2014. > > When NXP announced end of life of MPC 866 and 885, we bought enough CPUs > to be able to produce boards for the 10 following years so we still > produce some. > > MPC 8321 is still in production. > > All those boards are used in critical systems where we have a customer > requirement to keep all software including U-boot and Linux kernel up to > date, for IT security reason mainly. Firstly, thank you for the detailed reply - I totally appreciate how framing things with this detail was not without effort on your part. And your reasons for updating u-boot and the kernel are also valid. > Until now, the boards were delivered with kernel 4.14, with is due to > EOL early next year. > At the moment we are working on upgrading to mainline kernel with the > target being to be able to upgrade our customers to next LTS kernel at > the begining of 2024. > > Note that because our kernel code is prehistoric, it is not mergeable to > mainline. Not because of licence issues but because the code is just not > following at all linux standard. So our boards are not in mainline. Two > of them are in U-boot and the third one should soon be as well. > > So, to come back about the RDB boards, we have a couple of MPC 885 ADS > and a couple of MPC 8321 RDB. They are reference boards and we always > check that a given kernel version properly runs on them before starting > to port it to our hardware. Just as a reminder - I only mentioned RDB "for consideration". None of the RDB platforms were removed in this series. I don't want people to inadvertently conflate the two. > Hope it clarifies how those reference boards are used. It was really useful input and gave an insight into how things get used. But let me put a slightly different slant on things. If there is no maintainer for the platform/architecture/CPU, then where is the obligation for mainline to keep it up to date just for your company to use the code/BSP as a reference? Do they continue to do this for one more year, or three or ... ??? Does someone list themselves in MAINTAINERS for arch/powerpc/83xx ? Let us put that aside for now. I've worked with linux-next for decade+ and have a pretty good idea how all that "upstream stuff" works. If you have custom out-of-tree BSP and are interested in how upstream changes impact it, you should have nightly builds pulling down linux-next and applying your changes and finding when things break. If you see change 0123abcdef breaks boot on your platform, you have a legit voice to gripe about it right then and there. Don't wait!!! If you instead try and jump from v4.14 to v6.1 in one step, and then expect people to bisect on your behalf -- well good luck. The same applies to RDB boards - doesn't matter if they are in tree or support is applied manually. If they are of interest to you, then track and test regularly. It will save you a whole lot of bisect effort. Hope this helps, Paul. -- > > Christophe
On Fri, Mar 3, 2023, at 02:04, Paul Gortmaker wrote: > 01/03/2023 (Wed 14:23) Christophe Leroy wrote: >> Le 28/02/2023 ?? 18:51, Arnd Bergmann a ??crit??: >> Hope it clarifies how those reference boards are used. > > It was really useful input and gave an insight into how things get used. > > But let me put a slightly different slant on things. If there is no > maintainer for the platform/architecture/CPU, then where is the > obligation for mainline to keep it up to date just for your company to > use the code/BSP as a reference? > > Do they continue to do this for one more year, or three or ... ??? > Does someone list themselves in MAINTAINERS for arch/powerpc/83xx ? ... > > If you see change 0123abcdef breaks boot on your platform, you have a > legit voice to gripe about it right then and there. Don't wait!!! I think the answer here is that Christophe is already the only person that does this, so he is the de-facto maintainer for ppc32 regardless of whether he wants himself listed in the file or not: $ git log --no-merges --format="%an" v5.0.. arch/powerpc/platforms/[458e]* | sort | uniq -c | sort -rn | grep -vw 1 61 Christophe Leroy 12 Michael Ellerman 11 Thomas Gleixner 11 Oliver O'Halloran 11 Liang He 7 Uwe Kleine-König 6 Nick Child 4 Rasmus Villemoes 4 Randy Dunlap 4 Mike Rapoport 4 Julia Lawall 4 Andy Shevchenko 3 Xiaoming Ni 3 Nicholas Piggin 3 Marc Zyngier 3 Christophe JAILLET 3 Christoph Hellwig 2 Paul Gortmaker 2 Mathieu Malaterre 2 Markus Elfring 2 Jordan Niethe 2 Dmitry Torokhov 2 Arnd Bergmann Pretty much everyone else on the list above only did treewide cleanups, dead code removal or compile-time fixes, while Christophe is the one that fixed machine specific bugs and added new features. Arnd
On Fri, 2023-03-03 at 10:14 +0100, Arnd Bergmann wrote: > On Fri, Mar 3, 2023, at 02:04, Paul Gortmaker wrote: > > 01/03/2023 (Wed 14:23) Christophe Leroy wrote: > > > Le 28/02/2023 ?? 18:51, Arnd Bergmann a ??crit??: > > > Hope it clarifies how those reference boards are used. > > > > It was really useful input and gave an insight into how things get used. > > > > But let me put a slightly different slant on things. If there is no > > maintainer for the platform/architecture/CPU, then where is the > > obligation for mainline to keep it up to date just for your company to > > use the code/BSP as a reference? > > > > Do they continue to do this for one more year, or three or ... ??? > > Does someone list themselves in MAINTAINERS for arch/powerpc/83xx ? > ... > > > > If you see change 0123abcdef breaks boot on your platform, you have a > > legit voice to gripe about it right then and there. Don't wait!!! > > I think the answer here is that Christophe is already the only person > that does this, so he is the de-facto maintainer for ppc32 regardless > of whether he wants himself listed in the file or not: > > $ git log --no-merges --format="%an" v5.0.. arch/powerpc/platforms/[458e]* | > sort | uniq -c | sort -rn | grep -vw 1 > 61 Christophe Leroy > 12 Michael Ellerman > 11 Thomas Gleixner > 11 Oliver O'Halloran > 11 Liang He > 7 Uwe Kleine-König > 6 Nick Child > 4 Rasmus Villemoes > 4 Randy Dunlap > 4 Mike Rapoport > 4 Julia Lawall > 4 Andy Shevchenko > 3 Xiaoming Ni > 3 Nicholas Piggin > 3 Marc Zyngier > 3 Christophe JAILLET > 3 Christoph Hellwig > 2 Paul Gortmaker > 2 Mathieu Malaterre > 2 Markus Elfring > 2 Jordan Niethe > 2 Dmitry Torokhov > 2 Arnd Bergmann > > Pretty much everyone else on the list above only did treewide > cleanups, dead code removal or compile-time fixes, while Christophe > is the one that fixed machine specific bugs and added new features. Speaking of that, I'd be fine with Christophe replacing me in the "LINUX FOR POWERPC EMBEDDED PPC83XX AND PPC85XX" entry, given that he's been way more involved than me lately. -Crystal
Le 03/03/2023 à 20:41, Crystal Wood a écrit : > On Fri, 2023-03-03 at 10:14 +0100, Arnd Bergmann wrote: >> On Fri, Mar 3, 2023, at 02:04, Paul Gortmaker wrote: >>> 01/03/2023 (Wed 14:23) Christophe Leroy wrote: >>>> Le 28/02/2023 ?? 18:51, Arnd Bergmann a ??crit??: >>>> Hope it clarifies how those reference boards are used. >>> >>> It was really useful input and gave an insight into how things get used. >>> >>> But let me put a slightly different slant on things. If there is no >>> maintainer for the platform/architecture/CPU, then where is the >>> obligation for mainline to keep it up to date just for your company to >>> use the code/BSP as a reference? >>> >>> Do they continue to do this for one more year, or three or ... ??? >>> Does someone list themselves in MAINTAINERS for arch/powerpc/83xx ? >> ... >>> >>> If you see change 0123abcdef breaks boot on your platform, you have a >>> legit voice to gripe about it right then and there. Don't wait!!! >> >> I think the answer here is that Christophe is already the only person >> that does this, so he is the de-facto maintainer for ppc32 regardless >> of whether he wants himself listed in the file or not: >> >> $ git log --no-merges --format="%an" v5.0.. arch/powerpc/platforms/[458e]* | >> sort | uniq -c | sort -rn | grep -vw 1 >> 61 Christophe Leroy >> 12 Michael Ellerman >> 11 Thomas Gleixner >> 11 Oliver O'Halloran >> 11 Liang He >> 7 Uwe Kleine-König >> 6 Nick Child >> 4 Rasmus Villemoes >> 4 Randy Dunlap >> 4 Mike Rapoport >> 4 Julia Lawall >> 4 Andy Shevchenko >> 3 Xiaoming Ni >> 3 Nicholas Piggin >> 3 Marc Zyngier >> 3 Christophe JAILLET >> 3 Christoph Hellwig >> 2 Paul Gortmaker >> 2 Mathieu Malaterre >> 2 Markus Elfring >> 2 Jordan Niethe >> 2 Dmitry Torokhov >> 2 Arnd Bergmann >> >> Pretty much everyone else on the list above only did treewide >> cleanups, dead code removal or compile-time fixes, while Christophe >> is the one that fixed machine specific bugs and added new features. > > Speaking of that, I'd be fine with Christophe replacing me in the "LINUX FOR > POWERPC EMBEDDED PPC83XX AND PPC85XX" entry, given that he's been way more > involved than me lately. MPC83XX yes I can, I have MPC8321E Hardware, but PPC85XX I'm not sure. I don't know much more than what I can experiment with QEMU. Maybe Pali for MPC85XX ? Christophe
On Saturday 04 March 2023 07:31:49 Christophe Leroy wrote: > Le 03/03/2023 à 20:41, Crystal Wood a écrit : > > On Fri, 2023-03-03 at 10:14 +0100, Arnd Bergmann wrote: > >> On Fri, Mar 3, 2023, at 02:04, Paul Gortmaker wrote: > >>> 01/03/2023 (Wed 14:23) Christophe Leroy wrote: > >>>> Le 28/02/2023 ?? 18:51, Arnd Bergmann a ??crit??: > >>>> Hope it clarifies how those reference boards are used. > >>> > >>> It was really useful input and gave an insight into how things get used. > >>> > >>> But let me put a slightly different slant on things. If there is no > >>> maintainer for the platform/architecture/CPU, then where is the > >>> obligation for mainline to keep it up to date just for your company to > >>> use the code/BSP as a reference? > >>> > >>> Do they continue to do this for one more year, or three or ... ??? > >>> Does someone list themselves in MAINTAINERS for arch/powerpc/83xx ? > >> ... > >>> > >>> If you see change 0123abcdef breaks boot on your platform, you have a > >>> legit voice to gripe about it right then and there. Don't wait!!! > >> > >> I think the answer here is that Christophe is already the only person > >> that does this, so he is the de-facto maintainer for ppc32 regardless > >> of whether he wants himself listed in the file or not: > >> > >> $ git log --no-merges --format="%an" v5.0.. arch/powerpc/platforms/[458e]* | > >> sort | uniq -c | sort -rn | grep -vw 1 > >> 61 Christophe Leroy > >> 12 Michael Ellerman > >> 11 Thomas Gleixner > >> 11 Oliver O'Halloran > >> 11 Liang He > >> 7 Uwe Kleine-König > >> 6 Nick Child > >> 4 Rasmus Villemoes > >> 4 Randy Dunlap > >> 4 Mike Rapoport > >> 4 Julia Lawall > >> 4 Andy Shevchenko > >> 3 Xiaoming Ni > >> 3 Nicholas Piggin > >> 3 Marc Zyngier > >> 3 Christophe JAILLET > >> 3 Christoph Hellwig > >> 2 Paul Gortmaker > >> 2 Mathieu Malaterre > >> 2 Markus Elfring > >> 2 Jordan Niethe > >> 2 Dmitry Torokhov > >> 2 Arnd Bergmann > >> > >> Pretty much everyone else on the list above only did treewide > >> cleanups, dead code removal or compile-time fixes, while Christophe > >> is the one that fixed machine specific bugs and added new features. > > > > Speaking of that, I'd be fine with Christophe replacing me in the "LINUX FOR > > POWERPC EMBEDDED PPC83XX AND PPC85XX" entry, given that he's been way more > > involved than me lately. > > MPC83XX yes I can, I have MPC8321E Hardware, but PPC85XX I'm not sure. I > don't know much more than what I can experiment with QEMU. > > Maybe Pali for MPC85XX ? > > Christophe I have P2020 SMP HW (mpc85xx platform) which I use on daily usage. So yes, I can help. Martin Kennedy has other P1/P2 mpc85xx hardware and is working on Linux support for it. So maybe can be interested in this discussion. I'm CCing. I do not have mpc83xx HW.
On Sat, Mar 4, 2023 at 4:37 AM Pali Rohár <pali@kernel.org> wrote: > > On Saturday 04 March 2023 07:31:49 Christophe Leroy wrote: > > Le 03/03/2023 à 20:41, Crystal Wood a écrit : > > > On Fri, 2023-03-03 at 10:14 +0100, Arnd Bergmann wrote: > > >> On Fri, Mar 3, 2023, at 02:04, Paul Gortmaker wrote: > > >>> 01/03/2023 (Wed 14:23) Christophe Leroy wrote: > > >>>> Le 28/02/2023 ?? 18:51, Arnd Bergmann a ??crit??: > > >>>> Hope it clarifies how those reference boards are used. > > >>> > > >>> It was really useful input and gave an insight into how things get used. > > >>> > > >>> But let me put a slightly different slant on things. If there is no > > >>> maintainer for the platform/architecture/CPU, then where is the > > >>> obligation for mainline to keep it up to date just for your company to > > >>> use the code/BSP as a reference? > > >>> > > >>> Do they continue to do this for one more year, or three or ... ??? > > >>> Does someone list themselves in MAINTAINERS for arch/powerpc/83xx ? > > >> ... > > >>> > > >>> If you see change 0123abcdef breaks boot on your platform, you have a > > >>> legit voice to gripe about it right then and there. Don't wait!!! > > >> > > >> I think the answer here is that Christophe is already the only person > > >> that does this, so he is the de-facto maintainer for ppc32 regardless > > >> of whether he wants himself listed in the file or not: > > >> > > >> $ git log --no-merges --format="%an" v5.0.. arch/powerpc/platforms/[458e]* | > > >> sort | uniq -c | sort -rn | grep -vw 1 > > >> 61 Christophe Leroy > > >> 12 Michael Ellerman > > >> 11 Thomas Gleixner > > >> 11 Oliver O'Halloran > > >> 11 Liang He > > >> 7 Uwe Kleine-König > > >> 6 Nick Child > > >> 4 Rasmus Villemoes > > >> 4 Randy Dunlap > > >> 4 Mike Rapoport > > >> 4 Julia Lawall > > >> 4 Andy Shevchenko > > >> 3 Xiaoming Ni > > >> 3 Nicholas Piggin > > >> 3 Marc Zyngier > > >> 3 Christophe JAILLET > > >> 3 Christoph Hellwig > > >> 2 Paul Gortmaker > > >> 2 Mathieu Malaterre > > >> 2 Markus Elfring > > >> 2 Jordan Niethe > > >> 2 Dmitry Torokhov > > >> 2 Arnd Bergmann > > >> > > >> Pretty much everyone else on the list above only did treewide > > >> cleanups, dead code removal or compile-time fixes, while Christophe > > >> is the one that fixed machine specific bugs and added new features. > > > > > > Speaking of that, I'd be fine with Christophe replacing me in the "LINUX FOR > > > POWERPC EMBEDDED PPC83XX AND PPC85XX" entry, given that he's been way more > > > involved than me lately. > > > > MPC83XX yes I can, I have MPC8321E Hardware, but PPC85XX I'm not sure. I > > don't know much more than what I can experiment with QEMU. > > > > Maybe Pali for MPC85XX ? > > > > Christophe > > I have P2020 SMP HW (mpc85xx platform) which I use on daily usage. So yes, I can help. > > Martin Kennedy has other P1/P2 mpc85xx hardware and is working on Linux > support for it. So maybe can be interested in this discussion. I'm CCing. I have mpc85xx hardware, mostly access points adapted from the P1020WLAN board, but I am frankly a hobbyist. I do my work under OpenWrt, and I have no relationship with the manufacturers of these devices. I only catch regressions on my boards when changes are backported to the LTS kernel OpenWrt uses (so, presently, 5.15). Martin
"Arnd Bergmann" <arnd@arndb.de> writes: > On Fri, Mar 3, 2023, at 02:04, Paul Gortmaker wrote: >> 01/03/2023 (Wed 14:23) Christophe Leroy wrote: >>> Le 28/02/2023 ?? 18:51, Arnd Bergmann a ??crit??: >>> Hope it clarifies how those reference boards are used. >> >> It was really useful input and gave an insight into how things get used. >> >> But let me put a slightly different slant on things. If there is no >> maintainer for the platform/architecture/CPU, then where is the >> obligation for mainline to keep it up to date just for your company to >> use the code/BSP as a reference? >> >> Do they continue to do this for one more year, or three or ... ??? >> Does someone list themselves in MAINTAINERS for arch/powerpc/83xx ? > ... >> >> If you see change 0123abcdef breaks boot on your platform, you have a >> legit voice to gripe about it right then and there. Don't wait!!! > > I think the answer here is that Christophe is already the only person > that does this, so he is the de-facto maintainer for ppc32 regardless > of whether he wants himself listed in the file or not: Yes he is the de-facto 32-bit maintainer :) He's listed as a reviewer on the converged 64-bit/32-bit maintainers entry which is meant to reflect that: LINUX FOR POWERPC (32-BIT AND 64-BIT) M: Michael Ellerman <mpe@ellerman.id.au> R: Nicholas Piggin <npiggin@gmail.com> R: Christophe Leroy <christophe.leroy@csgroup.eu> L: linuxppc-dev@lists.ozlabs.org But we could add a separate 32-bit entry if people think that would make things clearer. Although I don't think we could run separate trees for 64-bit and 32-bit, there'd be too many conflicts, so in that way I think one entry makes sense. cheers
On Mon, 20 Feb 2023 06:59:09 -0500, Paul Gortmaker wrote: > [This RFC is proposed for v6.4 and hence is based off linux-next.] > > This series removes support for four e300 (MPC83xx) Freescale processor > family evaluation boards that were added to the kernel in the 2006 era. > > These boards were all of a very similar form factor, a largish PCI or PCI-X > card that could also be used standalone with an external power brick, and > all shared the Modular Development System (MDS) designation. > > [...] Applied to powerpc/next. [1/4] powerpc: drop MPC834x_MDS platform support https://git.kernel.org/powerpc/c/da03101799579f6477feb47a3aefcdb2e2379da1 [2/4] powerpc: drop MPC836x_MDS platform support https://git.kernel.org/powerpc/c/7840b08aeccbd4d46261a6d5c27699d6939f712e [3/4] powerpc: drop MPC837x_MDS platform support https://git.kernel.org/powerpc/c/aa572079633c293882d8fa3973bf6d8c27eb430f [4/4] powerpc: drop MPC832x_MDS platform support https://git.kernel.org/powerpc/c/b8fa3af2dbcb0c84270d4d2ecf54a088f7c90701 cheers