[U-Boot] [RFC] Eliminate boards not using CONFIG_DM=y
Dear maintainers,
we have been trying to move to the driver model for several years now. Starting in 2018 we have added warnings to the Makefile that boards not supporting the driver model will be eliminated. Still 24 % of the configuration files have not been converted and do not even use CONFIG_DM=y.
If we want to get rid of legacy drivers, at some point we have to remove the 347 configuration files in the list below not using the driver model.
I suggest to do this directly after the release of v2020.01 scheduled January 6th.
This should not stop the maintainers from reinserting the boards after conversion to the driver model.
Best regards
Heinrich
am3517_crane_defconfig apf27_defconfig apx4devkit_defconfig aristainetos2b_defconfig aristainetos2_defconfig aristainetos_defconfig aspenite_defconfig at91rm9200ek_defconfig at91rm9200ek_ram_defconfig B4420QDS_defconfig B4420QDS_NAND_defconfig B4420QDS_SPIFLASH_defconfig B4860QDS_defconfig B4860QDS_NAND_defconfig B4860QDS_SPIFLASH_defconfig B4860QDS_SRIO_PCIE_BOOT_defconfig bcm11130_defconfig bcm11130_nand_defconfig bcm23550_w1d_defconfig bcm28155_ap_defconfig bcm28155_w1d_defconfig bcm911360_entphn_defconfig bcm911360_entphn-ns_defconfig bcm911360k_defconfig bcm958300k_defconfig bcm958300k-ns_defconfig bcm958305k_defconfig bcm958622hr_defconfig bcm958712k_defconfig bg0900_defconfig BSC9131RDB_NAND_defconfig BSC9131RDB_NAND_SYSCLK100_defconfig BSC9131RDB_SPIFLASH_defconfig BSC9131RDB_SPIFLASH_SYSCLK100_defconfig BSC9132QDS_NAND_DDRCLK100_defconfig BSC9132QDS_NAND_DDRCLK133_defconfig BSC9132QDS_NOR_DDRCLK100_defconfig BSC9132QDS_NOR_DDRCLK133_defconfig BSC9132QDS_SDCARD_DDRCLK100_defconfig BSC9132QDS_SDCARD_DDRCLK133_defconfig BSC9132QDS_SPIFLASH_DDRCLK100_defconfig BSC9132QDS_SPIFLASH_DDRCLK133_defconfig C29XPCIE_defconfig C29XPCIE_NAND_defconfig C29XPCIE_SPIFLASH_defconfig caddy2_defconfig cm_t35_defconfig cm_t54_defconfig Cyrus_P5020_defconfig Cyrus_P5040_defconfig d2net_v2_defconfig dms-ba16-1g_defconfig dms-ba16_defconfig dockstar_defconfig duovero_defconfig edb9315a_defconfig edminiv2_defconfig flea3_defconfig gplugd_defconfig highbank_defconfig hrcon_defconfig hrcon_dh_defconfig ib62x0_defconfig iconnect_defconfig inetspace_v2_defconfig kc1_defconfig kmcoge4_defconfig kmcoge5ne_defconfig kmeter1_defconfig kmopti2_defconfig kmsupx5_defconfig kmtegr1_defconfig kmtepr2_defconfig ls2080a_emu_defconfig ls2080a_simu_defconfig MigoR_defconfig mpc8308_p1m_defconfig MPC8308RDB_defconfig MPC8313ERDB_33_defconfig MPC8313ERDB_66_defconfig MPC8313ERDB_NAND_33_defconfig MPC8313ERDB_NAND_66_defconfig MPC8315ERDB_defconfig MPC8323ERDB_defconfig MPC832XEMDS_ATM_defconfig MPC832XEMDS_defconfig MPC832XEMDS_HOST_33_defconfig MPC832XEMDS_HOST_66_defconfig MPC832XEMDS_SLAVE_defconfig MPC8349EMDS_defconfig MPC8349EMDS_PCI64_defconfig MPC8349EMDS_SDRAM_defconfig MPC8349EMDS_SLAVE_defconfig MPC8349ITX_defconfig MPC8349ITXGP_defconfig MPC8349ITX_LOWBOOT_defconfig MPC837XEMDS_defconfig MPC837XEMDS_HOST_defconfig MPC837XEMDS_SLAVE_defconfig MPC837XERDB_defconfig MPC837XERDB_SLAVE_defconfig MPC8536DS_36BIT_defconfig MPC8536DS_defconfig MPC8536DS_SDCARD_defconfig MPC8536DS_SPIFLASH_defconfig MPC8541CDS_defconfig MPC8541CDS_legacy_defconfig MPC8544DS_defconfig MPC8555CDS_defconfig MPC8555CDS_legacy_defconfig MPC8568MDS_defconfig MPC8569MDS_ATM_defconfig MPC8569MDS_defconfig MPC8572DS_36BIT_defconfig MPC8572DS_defconfig MPC8610HPCD_defconfig MPC8641HPCN_36BIT_defconfig MPC8641HPCN_defconfig mx23evk_defconfig mx23_olinuxino_defconfig mx25pdk_defconfig mx28evk_auart_console_defconfig mx28evk_defconfig mx28evk_nand_defconfig mx28evk_spi_defconfig mx31pdk_defconfig mx35pdk_defconfig mx51evk_defconfig mx53ard_defconfig mx53evk_defconfig mx53loco_defconfig mx53smd_defconfig mx6dlarm2_defconfig mx6dlarm2_lpddr2_defconfig mx6memcal_defconfig mx6qarm2_defconfig mx6qarm2_lpddr2_defconfig net2big_v2_defconfig netspace_lite_v2_defconfig netspace_max_v2_defconfig netspace_mini_v2_defconfig netspace_v2_defconfig nokia_rx51_defconfig nsa310s_defconfig omap3_ha_defconfig omap4_panda_defconfig omap4_sdp4430_defconfig omap5_uevm_defconfig openrd_base_defconfig openrd_client_defconfig openrd_ultimate_defconfig P1010RDB-PA_36BIT_NAND_defconfig P1010RDB-PA_36BIT_NOR_defconfig P1010RDB-PA_36BIT_SDCARD_defconfig P1010RDB-PA_36BIT_SPIFLASH_defconfig P1010RDB-PA_NAND_defconfig P1010RDB-PA_NOR_defconfig P1010RDB-PA_SDCARD_defconfig P1010RDB-PA_SPIFLASH_defconfig P1010RDB-PB_36BIT_NAND_defconfig P1010RDB-PB_36BIT_NOR_defconfig P1010RDB-PB_36BIT_SDCARD_defconfig P1010RDB-PB_36BIT_SPIFLASH_defconfig P1010RDB-PB_NAND_defconfig P1010RDB-PB_NOR_defconfig P1010RDB-PB_SDCARD_defconfig P1010RDB-PB_SPIFLASH_defconfig P1020MBG-PC_36BIT_defconfig P1020MBG-PC_36BIT_SDCARD_defconfig P1020MBG-PC_defconfig P1020MBG-PC_SDCARD_defconfig P1020UTM-PC_36BIT_defconfig P1020UTM-PC_36BIT_SDCARD_defconfig P1020UTM-PC_defconfig P1020UTM-PC_SDCARD_defconfig P1021RDB-PC_36BIT_defconfig P1021RDB-PC_36BIT_NAND_defconfig P1021RDB-PC_36BIT_SDCARD_defconfig P1021RDB-PC_36BIT_SPIFLASH_defconfig P1021RDB-PC_defconfig P1021RDB-PC_NAND_defconfig P1021RDB-PC_SDCARD_defconfig P1021RDB-PC_SPIFLASH_defconfig P1022DS_36BIT_defconfig P1022DS_36BIT_NAND_defconfig P1022DS_36BIT_SDCARD_defconfig P1022DS_36BIT_SPIFLASH_defconfig P1022DS_defconfig P1022DS_NAND_defconfig P1022DS_SDCARD_defconfig P1022DS_SPIFLASH_defconfig P1023RDB_defconfig P1024RDB_36BIT_defconfig P1024RDB_defconfig P1024RDB_NAND_defconfig P1024RDB_SDCARD_defconfig P1024RDB_SPIFLASH_defconfig P1025RDB_36BIT_defconfig P1025RDB_defconfig P1025RDB_NAND_defconfig P1025RDB_SDCARD_defconfig P1025RDB_SPIFLASH_defconfig P2041RDB_SRIO_PCIE_BOOT_defconfig P3041DS_SRIO_PCIE_BOOT_defconfig P4080DS_SRIO_PCIE_BOOT_defconfig P5020DS_defconfig P5020DS_NAND_defconfig P5020DS_SDCARD_defconfig P5020DS_SPIFLASH_defconfig P5020DS_SRIO_PCIE_BOOT_defconfig platinum_picon_defconfig platinum_titanium_defconfig pogo_e02_defconfig qemu_mips64_defconfig qemu_mips64el_defconfig qemu_mips_defconfig qemu_mipsel_defconfig qemu-ppce500_defconfig r7780mp_defconfig sansa_fuze_plus_defconfig sbc8349_defconfig sbc8349_PCI_33_defconfig sbc8349_PCI_66_defconfig sbc8548_defconfig sbc8548_PCI_33_defconfig sbc8548_PCI_33_PCIE_defconfig sbc8548_PCI_66_defconfig sbc8548_PCI_66_PCIE_defconfig sbc8641d_defconfig sc_sps_1_defconfig secomx6quq7_defconfig sh7752evb_defconfig sh7753evb_defconfig sh7757lcr_defconfig sh7763rdp_defconfig spear300_defconfig spear300_nand_defconfig spear300_usbtty_defconfig spear300_usbtty_nand_defconfig spear310_defconfig spear310_nand_defconfig spear310_pnor_defconfig spear310_usbtty_defconfig spear310_usbtty_nand_defconfig spear310_usbtty_pnor_defconfig spear320_defconfig spear320_nand_defconfig spear320_pnor_defconfig spear320_usbtty_defconfig spear320_usbtty_nand_defconfig spear320_usbtty_pnor_defconfig spear600_defconfig spear600_nand_defconfig spear600_usbtty_defconfig spear600_usbtty_nand_defconfig strider_con_defconfig strider_con_dp_defconfig strider_cpu_defconfig strider_cpu_dp_defconfig suvd3_defconfig T1023RDB_defconfig T1023RDB_NAND_defconfig T1023RDB_SDCARD_defconfig T1023RDB_SPIFLASH_defconfig T1024QDS_DDR4_defconfig T1024QDS_defconfig T1024QDS_NAND_defconfig T1024QDS_SDCARD_defconfig T1024QDS_SPIFLASH_defconfig T1040D4RDB_defconfig T1040D4RDB_NAND_defconfig T1040D4RDB_SDCARD_defconfig T1040D4RDB_SPIFLASH_defconfig T1040QDS_DDR4_defconfig T1040QDS_defconfig T1040RDB_defconfig T1040RDB_NAND_defconfig T1040RDB_SDCARD_defconfig T1040RDB_SPIFLASH_defconfig T1042RDB_defconfig T1042RDB_PI_defconfig T1042RDB_PI_NAND_defconfig T1042RDB_PI_SDCARD_defconfig T1042RDB_PI_SPIFLASH_defconfig T2080RDB_SRIO_PCIE_BOOT_defconfig T2081QDS_defconfig T2081QDS_NAND_defconfig T2081QDS_SDCARD_defconfig T2081QDS_SPIFLASH_defconfig T2081QDS_SRIO_PCIE_BOOT_defconfig T4160QDS_defconfig T4160QDS_NAND_defconfig T4160QDS_SDCARD_defconfig T4160RDB_defconfig T4240QDS_defconfig T4240QDS_NAND_defconfig T4240QDS_SDCARD_defconfig T4240QDS_SRIO_PCIE_BOOT_defconfig tao3530_defconfig ti814x_evm_defconfig titanium_defconfig TQM834x_defconfig tqma6dl_mba6_mmc_defconfig tqma6dl_mba6_spi_defconfig tqma6q_mba6_mmc_defconfig tqma6q_mba6_spi_defconfig tqma6s_mba6_mmc_defconfig tqma6s_mba6_spi_defconfig tqma6s_wru4_mmc_defconfig tricorder_defconfig tricorder_flash_defconfig ts4600_defconfig ts4800_defconfig tuge1_defconfig tuxx1_defconfig TWR-P1025_defconfig UCP1020_defconfig usbarmory_defconfig vct_platinumavc_defconfig vct_platinumavc_onenand_defconfig vct_platinumavc_onenand_small_defconfig vct_platinumavc_small_defconfig vct_platinum_defconfig vct_platinum_onenand_defconfig vct_platinum_onenand_small_defconfig vct_platinum_small_defconfig vct_premium_defconfig vct_premium_onenand_defconfig vct_premium_onenand_small_defconfig vct_premium_small_defconfig ve8313_defconfig vexpress_ca15_tc2_defconfig vexpress_ca5x2_defconfig vexpress_ca9x4_defconfig vme8349_defconfig warp_defconfig wb45n_defconfig wb50n_defconfig woodburn_defconfig woodburn_sd_defconfig x600_defconfig xfi3_defconfig xpedite517x_defconfig xpedite520x_defconfig xpedite537x_defconfig xpedite550x_defconfig zmx25_defconfig
On 11/26/19 12:16 AM, Heinrich Schuchardt wrote:
Dear maintainers,
Hi,
we have been trying to move to the driver model for several years now. Starting in 2018 we have added warnings to the Makefile that boards not supporting the driver model will be eliminated. Still 24 % of the configuration files have not been converted and do not even use CONFIG_DM=y.
If we want to get rid of legacy drivers, at some point we have to remove the 347 configuration files in the list below not using the driver model.
I suggest to do this directly after the release of v2020.01 scheduled January 6th.
This should not stop the maintainers from reinserting the boards after conversion to the driver model.
Some boards just cannot accommodate this DM stuff. For those boards, it's just bloat without any useful added value. Hence, these boards would be removed because they cannot accommodate arbitrary bloat. This makes U-Boot not-so-universal bootloader anymore, but rather a bloated one.
I don't think we can force boards out or impose DM on everyone unless we can solve this bloat issue first.
[...]
On Tue, Nov 26, 2019 at 09:11:51AM +0100, Marek Vasut wrote:
On 11/26/19 12:16 AM, Heinrich Schuchardt wrote:
Dear maintainers,
Hi,
we have been trying to move to the driver model for several years now. Starting in 2018 we have added warnings to the Makefile that boards not supporting the driver model will be eliminated. Still 24 % of the configuration files have not been converted and do not even use CONFIG_DM=y.
If we want to get rid of legacy drivers, at some point we have to remove the 347 configuration files in the list below not using the driver model.
I suggest to do this directly after the release of v2020.01 scheduled January 6th.
This should not stop the maintainers from reinserting the boards after conversion to the driver model.
Some boards just cannot accommodate this DM stuff. For those boards, it's just bloat without any useful added value. Hence, these boards would be removed because they cannot accommodate arbitrary bloat. This makes U-Boot not-so-universal bootloader anymore, but rather a bloated one.
I don't think we can force boards out or impose DM on everyone unless we can solve this bloat issue first.
As someone who was involved in creating this DM stuff, do you have some ideas on addressing things? Given that you're responsible for a number of these platforms and can test out some ideas on them, what are you suggesting?
Hi Tom,
On Tue, Nov 26, 2019 at 09:11:51AM +0100, Marek Vasut wrote:
On 11/26/19 12:16 AM, Heinrich Schuchardt wrote:
Dear maintainers,
Hi,
we have been trying to move to the driver model for several years now. Starting in 2018 we have added warnings to the Makefile that boards not supporting the driver model will be eliminated. Still 24 % of the configuration files have not been converted and do not even use CONFIG_DM=y.
If we want to get rid of legacy drivers, at some point we have to remove the 347 configuration files in the list below not using the driver model.
I suggest to do this directly after the release of v2020.01 scheduled January 6th.
This should not stop the maintainers from reinserting the boards after conversion to the driver model.
Some boards just cannot accommodate this DM stuff. For those boards, it's just bloat without any useful added value. Hence, these boards would be removed because they cannot accommodate arbitrary bloat. This makes U-Boot not-so-universal bootloader anymore, but rather a bloated one.
I don't think we can force boards out or impose DM on everyone unless we can solve this bloat issue first.
As someone who was involved in creating this DM stuff, do you have some ideas on addressing things? Given that you're responsible for a number of these platforms and can test out some ideas on them, what are you suggesting?
I can speak of some i.MX28 board(s). If there is a will one can try to use OF_PLATDATA without the full blown support of FDT (patches recently added to not include some not necessary stuff).
(The board which uses this approach still waits for SPL_DM_GPIO definition in Kconfig to be re-posted to ML)
However, I don't know if this would work for all kinds of _bloat_ mentioned by Marek.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
On Tue, Nov 26, 2019 at 05:31:26PM +0100, Lukasz Majewski wrote:
Hi Tom,
On Tue, Nov 26, 2019 at 09:11:51AM +0100, Marek Vasut wrote:
On 11/26/19 12:16 AM, Heinrich Schuchardt wrote:
Dear maintainers,
Hi,
we have been trying to move to the driver model for several years now. Starting in 2018 we have added warnings to the Makefile that boards not supporting the driver model will be eliminated. Still 24 % of the configuration files have not been converted and do not even use CONFIG_DM=y.
If we want to get rid of legacy drivers, at some point we have to remove the 347 configuration files in the list below not using the driver model.
I suggest to do this directly after the release of v2020.01 scheduled January 6th.
This should not stop the maintainers from reinserting the boards after conversion to the driver model.
Some boards just cannot accommodate this DM stuff. For those boards, it's just bloat without any useful added value. Hence, these boards would be removed because they cannot accommodate arbitrary bloat. This makes U-Boot not-so-universal bootloader anymore, but rather a bloated one.
I don't think we can force boards out or impose DM on everyone unless we can solve this bloat issue first.
As someone who was involved in creating this DM stuff, do you have some ideas on addressing things? Given that you're responsible for a number of these platforms and can test out some ideas on them, what are you suggesting?
I can speak of some i.MX28 board(s). If there is a will one can try to use OF_PLATDATA without the full blown support of FDT (patches recently added to not include some not necessary stuff).
Right, making use of OF_PLATDATA is one of the things to address bloat and DM isn't _required_ in SPL.
(The board which uses this approach still waits for SPL_DM_GPIO definition in Kconfig to be re-posted to ML)
Ah that patch. Sorry it's taking so long, I need to put it back on my to-grab list.
However, I don't know if this would work for all kinds of _bloat_ mentioned by Marek.
And "bloat" is something I'm actively looking for people to post some RFCs on how to address.
On 11/26/19 5:26 PM, Tom Rini wrote:
On Tue, Nov 26, 2019 at 09:11:51AM +0100, Marek Vasut wrote:
On 11/26/19 12:16 AM, Heinrich Schuchardt wrote:
Dear maintainers,
Hi,
we have been trying to move to the driver model for several years now. Starting in 2018 we have added warnings to the Makefile that boards not supporting the driver model will be eliminated. Still 24 % of the configuration files have not been converted and do not even use CONFIG_DM=y.
If we want to get rid of legacy drivers, at some point we have to remove the 347 configuration files in the list below not using the driver model.
I suggest to do this directly after the release of v2020.01 scheduled January 6th.
This should not stop the maintainers from reinserting the boards after conversion to the driver model.
Some boards just cannot accommodate this DM stuff. For those boards, it's just bloat without any useful added value. Hence, these boards would be removed because they cannot accommodate arbitrary bloat. This makes U-Boot not-so-universal bootloader anymore, but rather a bloated one.
I don't think we can force boards out or impose DM on everyone unless we can solve this bloat issue first.
As someone who was involved in creating this DM stuff, do you have some ideas on addressing things? Given that you're responsible for a number of these platforms and can test out some ideas on them, what are you suggesting?
How about directly calling driver functions for drivers which have single instance only ? Then we could optimize out all the DM overhead for that.
On Tue, Nov 26, 2019 at 05:47:48PM +0100, Marek Vasut wrote:
On 11/26/19 5:26 PM, Tom Rini wrote:
On Tue, Nov 26, 2019 at 09:11:51AM +0100, Marek Vasut wrote:
On 11/26/19 12:16 AM, Heinrich Schuchardt wrote:
Dear maintainers,
Hi,
we have been trying to move to the driver model for several years now. Starting in 2018 we have added warnings to the Makefile that boards not supporting the driver model will be eliminated. Still 24 % of the configuration files have not been converted and do not even use CONFIG_DM=y.
If we want to get rid of legacy drivers, at some point we have to remove the 347 configuration files in the list below not using the driver model.
I suggest to do this directly after the release of v2020.01 scheduled January 6th.
This should not stop the maintainers from reinserting the boards after conversion to the driver model.
Some boards just cannot accommodate this DM stuff. For those boards, it's just bloat without any useful added value. Hence, these boards would be removed because they cannot accommodate arbitrary bloat. This makes U-Boot not-so-universal bootloader anymore, but rather a bloated one.
I don't think we can force boards out or impose DM on everyone unless we can solve this bloat issue first.
As someone who was involved in creating this DM stuff, do you have some ideas on addressing things? Given that you're responsible for a number of these platforms and can test out some ideas on them, what are you suggesting?
How about directly calling driver functions for drivers which have single instance only ? Then we could optimize out all the DM overhead for that.
And when are you hoping to post an RFC / example?
On 11/26/19 5:52 PM, Tom Rini wrote:
On Tue, Nov 26, 2019 at 05:47:48PM +0100, Marek Vasut wrote:
On 11/26/19 5:26 PM, Tom Rini wrote:
On Tue, Nov 26, 2019 at 09:11:51AM +0100, Marek Vasut wrote:
On 11/26/19 12:16 AM, Heinrich Schuchardt wrote:
Dear maintainers,
Hi,
we have been trying to move to the driver model for several years now. Starting in 2018 we have added warnings to the Makefile that boards not supporting the driver model will be eliminated. Still 24 % of the configuration files have not been converted and do not even use CONFIG_DM=y.
If we want to get rid of legacy drivers, at some point we have to remove the 347 configuration files in the list below not using the driver model.
I suggest to do this directly after the release of v2020.01 scheduled January 6th.
This should not stop the maintainers from reinserting the boards after conversion to the driver model.
Some boards just cannot accommodate this DM stuff. For those boards, it's just bloat without any useful added value. Hence, these boards would be removed because they cannot accommodate arbitrary bloat. This makes U-Boot not-so-universal bootloader anymore, but rather a bloated one.
I don't think we can force boards out or impose DM on everyone unless we can solve this bloat issue first.
As someone who was involved in creating this DM stuff, do you have some ideas on addressing things? Given that you're responsible for a number of these platforms and can test out some ideas on them, what are you suggesting?
How about directly calling driver functions for drivers which have single instance only ? Then we could optimize out all the DM overhead for that.
And when are you hoping to post an RFC / example?
Currently I have zero time available. Maybe someone else can look into this option?
On 11/26/19 6:07 PM, Marek Vasut wrote:
On 11/26/19 5:52 PM, Tom Rini wrote:
On Tue, Nov 26, 2019 at 05:47:48PM +0100, Marek Vasut wrote:
On 11/26/19 5:26 PM, Tom Rini wrote:
On Tue, Nov 26, 2019 at 09:11:51AM +0100, Marek Vasut wrote:
On 11/26/19 12:16 AM, Heinrich Schuchardt wrote:
Dear maintainers,
Hi,
we have been trying to move to the driver model for several years now. Starting in 2018 we have added warnings to the Makefile that boards not supporting the driver model will be eliminated. Still 24 % of the configuration files have not been converted and do not even use CONFIG_DM=y.
If we want to get rid of legacy drivers, at some point we have to remove the 347 configuration files in the list below not using the driver model.
I suggest to do this directly after the release of v2020.01 scheduled January 6th.
This should not stop the maintainers from reinserting the boards after conversion to the driver model.
Some boards just cannot accommodate this DM stuff. For those boards, it's just bloat without any useful added value. Hence, these boards would be removed because they cannot accommodate arbitrary bloat. This makes U-Boot not-so-universal bootloader anymore, but rather a bloated one.
I don't think we can force boards out or impose DM on everyone unless we can solve this bloat issue first.
As someone who was involved in creating this DM stuff, do you have some ideas on addressing things? Given that you're responsible for a number of these platforms and can test out some ideas on them, what are you suggesting?
How about directly calling driver functions for drivers which have single instance only ? Then we could optimize out all the DM overhead for that.
And when are you hoping to post an RFC / example?
Currently I have zero time available. Maybe someone else can look into this option?
Dear Marex,
DM drivers make use of the DM infrastructure for instance for the allocation of the private data area. The uclass files often include common logic needed for accessing all drivers (see for example tpm_xfer()).
So which drivers do you think of that could be simplified?
I would also be interested to learn which of the 347 boards not using CONFIG_DM=y are still actively maintained.
Best regards
Heinrich
On 11/28/19 7:22 AM, Heinrich Schuchardt wrote:
On 11/26/19 6:07 PM, Marek Vasut wrote:
On 11/26/19 5:52 PM, Tom Rini wrote:
On Tue, Nov 26, 2019 at 05:47:48PM +0100, Marek Vasut wrote:
On 11/26/19 5:26 PM, Tom Rini wrote:
On Tue, Nov 26, 2019 at 09:11:51AM +0100, Marek Vasut wrote:
On 11/26/19 12:16 AM, Heinrich Schuchardt wrote: > Dear maintainers,
Hi,
> we have been trying to move to the driver model for several years > now. > Starting in 2018 we have added warnings to the Makefile that > boards not > supporting the driver model will be eliminated. Still 24 % of the > configuration files have not been converted and do not even use > CONFIG_DM=y. > > If we want to get rid of legacy drivers, at some point we have to > remove > the 347 configuration files in the list below not using the > driver model. > > I suggest to do this directly after the release of v2020.01 > scheduled > January 6th. > > This should not stop the maintainers from reinserting the boards > after > conversion to the driver model.
Some boards just cannot accommodate this DM stuff. For those boards, it's just bloat without any useful added value. Hence, these boards would be removed because they cannot accommodate arbitrary bloat. This makes U-Boot not-so-universal bootloader anymore, but rather a bloated one.
I don't think we can force boards out or impose DM on everyone unless we can solve this bloat issue first.
As someone who was involved in creating this DM stuff, do you have some ideas on addressing things? Given that you're responsible for a number of these platforms and can test out some ideas on them, what are you suggesting?
How about directly calling driver functions for drivers which have single instance only ? Then we could optimize out all the DM overhead for that.
And when are you hoping to post an RFC / example?
Currently I have zero time available. Maybe someone else can look into this option?
Dear Marex,
DM drivers make use of the DM infrastructure for instance for the allocation of the private data area. The uclass files often include common logic needed for accessing all drivers (see for example tpm_xfer()).
So which drivers do you think of that could be simplified?
UART for example ? You only usually have one.
I would also be interested to learn which of the 347 boards not using CONFIG_DM=y are still actively maintained.
Probably quite a few of those iMX, omap and PPC ones. The qemu ones are probably used for CI ?
On Thu, Nov 28, 2019 at 10:40:38AM +0100, Marek Vasut wrote:
On 11/28/19 7:22 AM, Heinrich Schuchardt wrote:
On 11/26/19 6:07 PM, Marek Vasut wrote:
On 11/26/19 5:52 PM, Tom Rini wrote:
On Tue, Nov 26, 2019 at 05:47:48PM +0100, Marek Vasut wrote:
On 11/26/19 5:26 PM, Tom Rini wrote:
On Tue, Nov 26, 2019 at 09:11:51AM +0100, Marek Vasut wrote: > On 11/26/19 12:16 AM, Heinrich Schuchardt wrote: >> Dear maintainers, > > Hi, > >> we have been trying to move to the driver model for several years >> now. >> Starting in 2018 we have added warnings to the Makefile that >> boards not >> supporting the driver model will be eliminated. Still 24 % of the >> configuration files have not been converted and do not even use >> CONFIG_DM=y. >> >> If we want to get rid of legacy drivers, at some point we have to >> remove >> the 347 configuration files in the list below not using the >> driver model. >> >> I suggest to do this directly after the release of v2020.01 >> scheduled >> January 6th. >> >> This should not stop the maintainers from reinserting the boards >> after >> conversion to the driver model. > > Some boards just cannot accommodate this DM stuff. For those boards, > it's just bloat without any useful added value. Hence, these boards > would be removed because they cannot accommodate arbitrary bloat. > This > makes U-Boot not-so-universal bootloader anymore, but rather a > bloated one. > > I don't think we can force boards out or impose DM on everyone > unless we > can solve this bloat issue first.
As someone who was involved in creating this DM stuff, do you have some ideas on addressing things? Given that you're responsible for a number of these platforms and can test out some ideas on them, what are you suggesting?
How about directly calling driver functions for drivers which have single instance only ? Then we could optimize out all the DM overhead for that.
And when are you hoping to post an RFC / example?
Currently I have zero time available. Maybe someone else can look into this option?
Dear Marex,
DM drivers make use of the DM infrastructure for instance for the allocation of the private data area. The uclass files often include common logic needed for accessing all drivers (see for example tpm_xfer()).
So which drivers do you think of that could be simplified?
UART for example ? You only usually have one.
I would also be interested to learn which of the 347 boards not using CONFIG_DM=y are still actively maintained.
Probably quite a few of those iMX, omap and PPC ones. The qemu ones are probably used for CI ?
I need to reply more directly to the opening post but yes, i.MX is still for various reasons needing help, and no, shouldn't be dropped, but we need to have a serious conversation about it. The OMAP platforms probably could be dropped or need a quick conversion. PowerPC is another place where we need a serious conversation. MIPS I think just needs some updating for conversion, along with the vexpress ones we also use in CI via QEMU.
-----Original Message----- From: U-Boot-Custodians u-boot-custodians-bounces@lists.denx.de On Behalf Of Heinrich Schuchardt Sent: Tuesday, November 26, 2019 4:46 AM To: u-boot-custodians@lists.denx.de; u-boot-board- maintainers@lists.denx.de; U-Boot Mailing List u-boot@lists.denx.de Subject: [U-Boot-Custodians] [RFC] Eliminate boards not using CONFIG_DM=y
Dear maintainers,
we have been trying to move to the driver model for several years now. Starting in 2018 we have added warnings to the Makefile that boards not supporting the driver model will be eliminated. Still 24 % of the configuration files have not been converted and do not even use CONFIG_DM=y.
If we want to get rid of legacy drivers, at some point we have to remove the 347 configuration files in the list below not using the driver model.
I suggest to do this directly after the release of v2020.01 scheduled January 6th.
This should not stop the maintainers from reinserting the boards after conversion to the driver model.
Best regards
Heinrich
am3517_crane_defconfig apf27_defconfig apx4devkit_defconfig aristainetos2b_defconfig aristainetos2_defconfig aristainetos_defconfig aspenite_defconfig at91rm9200ek_defconfig at91rm9200ek_ram_defconfig B4420QDS_defconfig B4420QDS_NAND_defconfig B4420QDS_SPIFLASH_defconfig B4860QDS_defconfig B4860QDS_NAND_defconfig B4860QDS_SPIFLASH_defconfig B4860QDS_SRIO_PCIE_BOOT_defconfig bcm11130_defconfig bcm11130_nand_defconfig bcm23550_w1d_defconfig bcm28155_ap_defconfig bcm28155_w1d_defconfig bcm911360_entphn_defconfig bcm911360_entphn-ns_defconfig bcm911360k_defconfig bcm958300k_defconfig bcm958300k-ns_defconfig bcm958305k_defconfig bcm958622hr_defconfig bcm958712k_defconfig bg0900_defconfig BSC9131RDB_NAND_defconfig BSC9131RDB_NAND_SYSCLK100_defconfig BSC9131RDB_SPIFLASH_defconfig BSC9131RDB_SPIFLASH_SYSCLK100_defconfig BSC9132QDS_NAND_DDRCLK100_defconfig BSC9132QDS_NAND_DDRCLK133_defconfig BSC9132QDS_NOR_DDRCLK100_defconfig BSC9132QDS_NOR_DDRCLK133_defconfig BSC9132QDS_SDCARD_DDRCLK100_defconfig BSC9132QDS_SDCARD_DDRCLK133_defconfig BSC9132QDS_SPIFLASH_DDRCLK100_defconfig BSC9132QDS_SPIFLASH_DDRCLK133_defconfig C29XPCIE_defconfig C29XPCIE_NAND_defconfig C29XPCIE_SPIFLASH_defconfig caddy2_defconfig cm_t35_defconfig cm_t54_defconfig Cyrus_P5020_defconfig Cyrus_P5040_defconfig d2net_v2_defconfig dms-ba16-1g_defconfig dms-ba16_defconfig dockstar_defconfig duovero_defconfig edb9315a_defconfig edminiv2_defconfig flea3_defconfig gplugd_defconfig highbank_defconfig hrcon_defconfig hrcon_dh_defconfig ib62x0_defconfig iconnect_defconfig inetspace_v2_defconfig kc1_defconfig kmcoge4_defconfig kmcoge5ne_defconfig kmeter1_defconfig kmopti2_defconfig kmsupx5_defconfig kmtegr1_defconfig kmtepr2_defconfig ls2080a_emu_defconfig ls2080a_simu_defconfig MigoR_defconfig mpc8308_p1m_defconfig MPC8308RDB_defconfig MPC8313ERDB_33_defconfig MPC8313ERDB_66_defconfig MPC8313ERDB_NAND_33_defconfig MPC8313ERDB_NAND_66_defconfig MPC8315ERDB_defconfig MPC8323ERDB_defconfig MPC832XEMDS_ATM_defconfig MPC832XEMDS_defconfig MPC832XEMDS_HOST_33_defconfig MPC832XEMDS_HOST_66_defconfig MPC832XEMDS_SLAVE_defconfig MPC8349EMDS_defconfig MPC8349EMDS_PCI64_defconfig MPC8349EMDS_SDRAM_defconfig MPC8349EMDS_SLAVE_defconfig MPC8349ITX_defconfig MPC8349ITXGP_defconfig MPC8349ITX_LOWBOOT_defconfig MPC837XEMDS_defconfig MPC837XEMDS_HOST_defconfig MPC837XEMDS_SLAVE_defconfig MPC837XERDB_defconfig MPC837XERDB_SLAVE_defconfig MPC8536DS_36BIT_defconfig MPC8536DS_defconfig MPC8536DS_SDCARD_defconfig MPC8536DS_SPIFLASH_defconfig MPC8541CDS_defconfig MPC8541CDS_legacy_defconfig MPC8544DS_defconfig MPC8555CDS_defconfig MPC8555CDS_legacy_defconfig MPC8568MDS_defconfig MPC8569MDS_ATM_defconfig MPC8569MDS_defconfig MPC8572DS_36BIT_defconfig MPC8572DS_defconfig MPC8610HPCD_defconfig MPC8641HPCN_36BIT_defconfig MPC8641HPCN_defconfig mx23evk_defconfig mx23_olinuxino_defconfig mx25pdk_defconfig mx28evk_auart_console_defconfig mx28evk_defconfig mx28evk_nand_defconfig mx28evk_spi_defconfig mx31pdk_defconfig mx35pdk_defconfig mx51evk_defconfig mx53ard_defconfig mx53evk_defconfig mx53loco_defconfig mx53smd_defconfig mx6dlarm2_defconfig mx6dlarm2_lpddr2_defconfig mx6memcal_defconfig mx6qarm2_defconfig mx6qarm2_lpddr2_defconfig net2big_v2_defconfig netspace_lite_v2_defconfig netspace_max_v2_defconfig netspace_mini_v2_defconfig netspace_v2_defconfig nokia_rx51_defconfig nsa310s_defconfig omap3_ha_defconfig omap4_panda_defconfig omap4_sdp4430_defconfig omap5_uevm_defconfig openrd_base_defconfig openrd_client_defconfig openrd_ultimate_defconfig P1010RDB-PA_36BIT_NAND_defconfig P1010RDB-PA_36BIT_NOR_defconfig P1010RDB-PA_36BIT_SDCARD_defconfig P1010RDB-PA_36BIT_SPIFLASH_defconfig P1010RDB-PA_NAND_defconfig P1010RDB-PA_NOR_defconfig P1010RDB-PA_SDCARD_defconfig P1010RDB-PA_SPIFLASH_defconfig P1010RDB-PB_36BIT_NAND_defconfig P1010RDB-PB_36BIT_NOR_defconfig P1010RDB-PB_36BIT_SDCARD_defconfig P1010RDB-PB_36BIT_SPIFLASH_defconfig P1010RDB-PB_NAND_defconfig P1010RDB-PB_NOR_defconfig P1010RDB-PB_SDCARD_defconfig P1010RDB-PB_SPIFLASH_defconfig P1020MBG-PC_36BIT_defconfig P1020MBG-PC_36BIT_SDCARD_defconfig P1020MBG-PC_defconfig P1020MBG-PC_SDCARD_defconfig P1020UTM-PC_36BIT_defconfig P1020UTM-PC_36BIT_SDCARD_defconfig P1020UTM-PC_defconfig P1020UTM-PC_SDCARD_defconfig P1021RDB-PC_36BIT_defconfig P1021RDB-PC_36BIT_NAND_defconfig P1021RDB-PC_36BIT_SDCARD_defconfig P1021RDB-PC_36BIT_SPIFLASH_defconfig P1021RDB-PC_defconfig P1021RDB-PC_NAND_defconfig P1021RDB-PC_SDCARD_defconfig P1021RDB-PC_SPIFLASH_defconfig P1022DS_36BIT_defconfig P1022DS_36BIT_NAND_defconfig P1022DS_36BIT_SDCARD_defconfig P1022DS_36BIT_SPIFLASH_defconfig P1022DS_defconfig P1022DS_NAND_defconfig P1022DS_SDCARD_defconfig P1022DS_SPIFLASH_defconfig P1023RDB_defconfig P1024RDB_36BIT_defconfig P1024RDB_defconfig P1024RDB_NAND_defconfig P1024RDB_SDCARD_defconfig P1024RDB_SPIFLASH_defconfig P1025RDB_36BIT_defconfig P1025RDB_defconfig P1025RDB_NAND_defconfig P1025RDB_SDCARD_defconfig P1025RDB_SPIFLASH_defconfig P2041RDB_SRIO_PCIE_BOOT_defconfig P3041DS_SRIO_PCIE_BOOT_defconfig P4080DS_SRIO_PCIE_BOOT_defconfig P5020DS_defconfig P5020DS_NAND_defconfig P5020DS_SDCARD_defconfig P5020DS_SPIFLASH_defconfig P5020DS_SRIO_PCIE_BOOT_defconfig platinum_picon_defconfig platinum_titanium_defconfig pogo_e02_defconfig qemu_mips64_defconfig qemu_mips64el_defconfig qemu_mips_defconfig qemu_mipsel_defconfig qemu-ppce500_defconfig r7780mp_defconfig sansa_fuze_plus_defconfig sbc8349_defconfig sbc8349_PCI_33_defconfig sbc8349_PCI_66_defconfig sbc8548_defconfig sbc8548_PCI_33_defconfig sbc8548_PCI_33_PCIE_defconfig sbc8548_PCI_66_defconfig sbc8548_PCI_66_PCIE_defconfig sbc8641d_defconfig sc_sps_1_defconfig secomx6quq7_defconfig sh7752evb_defconfig sh7753evb_defconfig sh7757lcr_defconfig sh7763rdp_defconfig spear300_defconfig spear300_nand_defconfig spear300_usbtty_defconfig spear300_usbtty_nand_defconfig spear310_defconfig spear310_nand_defconfig spear310_pnor_defconfig spear310_usbtty_defconfig spear310_usbtty_nand_defconfig spear310_usbtty_pnor_defconfig spear320_defconfig spear320_nand_defconfig spear320_pnor_defconfig spear320_usbtty_defconfig spear320_usbtty_nand_defconfig spear320_usbtty_pnor_defconfig spear600_defconfig spear600_nand_defconfig spear600_usbtty_defconfig spear600_usbtty_nand_defconfig strider_con_defconfig strider_con_dp_defconfig strider_cpu_defconfig strider_cpu_dp_defconfig suvd3_defconfig T1023RDB_defconfig T1023RDB_NAND_defconfig T1023RDB_SDCARD_defconfig T1023RDB_SPIFLASH_defconfig T1024QDS_DDR4_defconfig T1024QDS_defconfig T1024QDS_NAND_defconfig T1024QDS_SDCARD_defconfig T1024QDS_SPIFLASH_defconfig T1040D4RDB_defconfig T1040D4RDB_NAND_defconfig T1040D4RDB_SDCARD_defconfig T1040D4RDB_SPIFLASH_defconfig T1040QDS_DDR4_defconfig T1040QDS_defconfig T1040RDB_defconfig T1040RDB_NAND_defconfig T1040RDB_SDCARD_defconfig T1040RDB_SPIFLASH_defconfig T1042RDB_defconfig T1042RDB_PI_defconfig T1042RDB_PI_NAND_defconfig T1042RDB_PI_SDCARD_defconfig T1042RDB_PI_SPIFLASH_defconfig T2080RDB_SRIO_PCIE_BOOT_defconfig T2081QDS_defconfig T2081QDS_NAND_defconfig T2081QDS_SDCARD_defconfig T2081QDS_SPIFLASH_defconfig T2081QDS_SRIO_PCIE_BOOT_defconfig T4160QDS_defconfig T4160QDS_NAND_defconfig T4160QDS_SDCARD_defconfig T4160RDB_defconfig T4240QDS_defconfig T4240QDS_NAND_defconfig T4240QDS_SDCARD_defconfig T4240QDS_SRIO_PCIE_BOOT_defconfig tao3530_defconfig ti814x_evm_defconfig titanium_defconfig TQM834x_defconfig tqma6dl_mba6_mmc_defconfig tqma6dl_mba6_spi_defconfig tqma6q_mba6_mmc_defconfig tqma6q_mba6_spi_defconfig tqma6s_mba6_mmc_defconfig tqma6s_mba6_spi_defconfig tqma6s_wru4_mmc_defconfig tricorder_defconfig tricorder_flash_defconfig ts4600_defconfig ts4800_defconfig tuge1_defconfig tuxx1_defconfig TWR-P1025_defconfig UCP1020_defconfig usbarmory_defconfig vct_platinumavc_defconfig vct_platinumavc_onenand_defconfig vct_platinumavc_onenand_small_defconfig vct_platinumavc_small_defconfig vct_platinum_defconfig vct_platinum_onenand_defconfig vct_platinum_onenand_small_defconfig vct_platinum_small_defconfig vct_premium_defconfig vct_premium_onenand_defconfig vct_premium_onenand_small_defconfig vct_premium_small_defconfig ve8313_defconfig vexpress_ca15_tc2_defconfig vexpress_ca5x2_defconfig vexpress_ca9x4_defconfig vme8349_defconfig warp_defconfig wb45n_defconfig wb50n_defconfig woodburn_defconfig woodburn_sd_defconfig x600_defconfig xfi3_defconfig xpedite517x_defconfig xpedite520x_defconfig xpedite537x_defconfig xpedite550x_defconfig zmx25_defconfig _______________________________________________
NXP Engineers are working on migration of NXP powerpc platforms like B4, BSC913x, C29X, P1010, P102x, P2041,P3041, P4080, P5020, P1025, T102x, T104x, T208x, T4160, T4240, etc series Some Patches are in already in review and are dependent on feature merger of https://patchwork.ozlabs.org/project/uboot/list/?series=129069&state=*
Please don’t remove them.
-priyankajain <snip>
On Fri, Nov 29, 2019 at 06:46:40AM +0000, Priyanka Jain wrote:
-----Original Message----- From: U-Boot-Custodians u-boot-custodians-bounces@lists.denx.de On Behalf Of Heinrich Schuchardt Sent: Tuesday, November 26, 2019 4:46 AM To: u-boot-custodians@lists.denx.de; u-boot-board- maintainers@lists.denx.de; U-Boot Mailing List u-boot@lists.denx.de Subject: [U-Boot-Custodians] [RFC] Eliminate boards not using CONFIG_DM=y
Dear maintainers,
we have been trying to move to the driver model for several years now. Starting in 2018 we have added warnings to the Makefile that boards not supporting the driver model will be eliminated. Still 24 % of the configuration files have not been converted and do not even use CONFIG_DM=y.
If we want to get rid of legacy drivers, at some point we have to remove the 347 configuration files in the list below not using the driver model.
I suggest to do this directly after the release of v2020.01 scheduled January 6th.
This should not stop the maintainers from reinserting the boards after conversion to the driver model.
Best regards
Heinrich
am3517_crane_defconfig apf27_defconfig apx4devkit_defconfig aristainetos2b_defconfig aristainetos2_defconfig aristainetos_defconfig aspenite_defconfig at91rm9200ek_defconfig at91rm9200ek_ram_defconfig B4420QDS_defconfig B4420QDS_NAND_defconfig B4420QDS_SPIFLASH_defconfig B4860QDS_defconfig B4860QDS_NAND_defconfig B4860QDS_SPIFLASH_defconfig B4860QDS_SRIO_PCIE_BOOT_defconfig bcm11130_defconfig bcm11130_nand_defconfig bcm23550_w1d_defconfig bcm28155_ap_defconfig bcm28155_w1d_defconfig bcm911360_entphn_defconfig bcm911360_entphn-ns_defconfig bcm911360k_defconfig bcm958300k_defconfig bcm958300k-ns_defconfig bcm958305k_defconfig bcm958622hr_defconfig bcm958712k_defconfig bg0900_defconfig BSC9131RDB_NAND_defconfig BSC9131RDB_NAND_SYSCLK100_defconfig BSC9131RDB_SPIFLASH_defconfig BSC9131RDB_SPIFLASH_SYSCLK100_defconfig BSC9132QDS_NAND_DDRCLK100_defconfig BSC9132QDS_NAND_DDRCLK133_defconfig BSC9132QDS_NOR_DDRCLK100_defconfig BSC9132QDS_NOR_DDRCLK133_defconfig BSC9132QDS_SDCARD_DDRCLK100_defconfig BSC9132QDS_SDCARD_DDRCLK133_defconfig BSC9132QDS_SPIFLASH_DDRCLK100_defconfig BSC9132QDS_SPIFLASH_DDRCLK133_defconfig C29XPCIE_defconfig C29XPCIE_NAND_defconfig C29XPCIE_SPIFLASH_defconfig caddy2_defconfig cm_t35_defconfig cm_t54_defconfig Cyrus_P5020_defconfig Cyrus_P5040_defconfig d2net_v2_defconfig dms-ba16-1g_defconfig dms-ba16_defconfig dockstar_defconfig duovero_defconfig edb9315a_defconfig edminiv2_defconfig flea3_defconfig gplugd_defconfig highbank_defconfig hrcon_defconfig hrcon_dh_defconfig ib62x0_defconfig iconnect_defconfig inetspace_v2_defconfig kc1_defconfig kmcoge4_defconfig kmcoge5ne_defconfig kmeter1_defconfig kmopti2_defconfig kmsupx5_defconfig kmtegr1_defconfig kmtepr2_defconfig ls2080a_emu_defconfig ls2080a_simu_defconfig MigoR_defconfig mpc8308_p1m_defconfig MPC8308RDB_defconfig MPC8313ERDB_33_defconfig MPC8313ERDB_66_defconfig MPC8313ERDB_NAND_33_defconfig MPC8313ERDB_NAND_66_defconfig MPC8315ERDB_defconfig MPC8323ERDB_defconfig MPC832XEMDS_ATM_defconfig MPC832XEMDS_defconfig MPC832XEMDS_HOST_33_defconfig MPC832XEMDS_HOST_66_defconfig MPC832XEMDS_SLAVE_defconfig MPC8349EMDS_defconfig MPC8349EMDS_PCI64_defconfig MPC8349EMDS_SDRAM_defconfig MPC8349EMDS_SLAVE_defconfig MPC8349ITX_defconfig MPC8349ITXGP_defconfig MPC8349ITX_LOWBOOT_defconfig MPC837XEMDS_defconfig MPC837XEMDS_HOST_defconfig MPC837XEMDS_SLAVE_defconfig MPC837XERDB_defconfig MPC837XERDB_SLAVE_defconfig MPC8536DS_36BIT_defconfig MPC8536DS_defconfig MPC8536DS_SDCARD_defconfig MPC8536DS_SPIFLASH_defconfig MPC8541CDS_defconfig MPC8541CDS_legacy_defconfig MPC8544DS_defconfig MPC8555CDS_defconfig MPC8555CDS_legacy_defconfig MPC8568MDS_defconfig MPC8569MDS_ATM_defconfig MPC8569MDS_defconfig MPC8572DS_36BIT_defconfig MPC8572DS_defconfig MPC8610HPCD_defconfig MPC8641HPCN_36BIT_defconfig MPC8641HPCN_defconfig mx23evk_defconfig mx23_olinuxino_defconfig mx25pdk_defconfig mx28evk_auart_console_defconfig mx28evk_defconfig mx28evk_nand_defconfig mx28evk_spi_defconfig mx31pdk_defconfig mx35pdk_defconfig mx51evk_defconfig mx53ard_defconfig mx53evk_defconfig mx53loco_defconfig mx53smd_defconfig mx6dlarm2_defconfig mx6dlarm2_lpddr2_defconfig mx6memcal_defconfig mx6qarm2_defconfig mx6qarm2_lpddr2_defconfig net2big_v2_defconfig netspace_lite_v2_defconfig netspace_max_v2_defconfig netspace_mini_v2_defconfig netspace_v2_defconfig nokia_rx51_defconfig nsa310s_defconfig omap3_ha_defconfig omap4_panda_defconfig omap4_sdp4430_defconfig omap5_uevm_defconfig openrd_base_defconfig openrd_client_defconfig openrd_ultimate_defconfig P1010RDB-PA_36BIT_NAND_defconfig P1010RDB-PA_36BIT_NOR_defconfig P1010RDB-PA_36BIT_SDCARD_defconfig P1010RDB-PA_36BIT_SPIFLASH_defconfig P1010RDB-PA_NAND_defconfig P1010RDB-PA_NOR_defconfig P1010RDB-PA_SDCARD_defconfig P1010RDB-PA_SPIFLASH_defconfig P1010RDB-PB_36BIT_NAND_defconfig P1010RDB-PB_36BIT_NOR_defconfig P1010RDB-PB_36BIT_SDCARD_defconfig P1010RDB-PB_36BIT_SPIFLASH_defconfig P1010RDB-PB_NAND_defconfig P1010RDB-PB_NOR_defconfig P1010RDB-PB_SDCARD_defconfig P1010RDB-PB_SPIFLASH_defconfig P1020MBG-PC_36BIT_defconfig P1020MBG-PC_36BIT_SDCARD_defconfig P1020MBG-PC_defconfig P1020MBG-PC_SDCARD_defconfig P1020UTM-PC_36BIT_defconfig P1020UTM-PC_36BIT_SDCARD_defconfig P1020UTM-PC_defconfig P1020UTM-PC_SDCARD_defconfig P1021RDB-PC_36BIT_defconfig P1021RDB-PC_36BIT_NAND_defconfig P1021RDB-PC_36BIT_SDCARD_defconfig P1021RDB-PC_36BIT_SPIFLASH_defconfig P1021RDB-PC_defconfig P1021RDB-PC_NAND_defconfig P1021RDB-PC_SDCARD_defconfig P1021RDB-PC_SPIFLASH_defconfig P1022DS_36BIT_defconfig P1022DS_36BIT_NAND_defconfig P1022DS_36BIT_SDCARD_defconfig P1022DS_36BIT_SPIFLASH_defconfig P1022DS_defconfig P1022DS_NAND_defconfig P1022DS_SDCARD_defconfig P1022DS_SPIFLASH_defconfig P1023RDB_defconfig P1024RDB_36BIT_defconfig P1024RDB_defconfig P1024RDB_NAND_defconfig P1024RDB_SDCARD_defconfig P1024RDB_SPIFLASH_defconfig P1025RDB_36BIT_defconfig P1025RDB_defconfig P1025RDB_NAND_defconfig P1025RDB_SDCARD_defconfig P1025RDB_SPIFLASH_defconfig P2041RDB_SRIO_PCIE_BOOT_defconfig P3041DS_SRIO_PCIE_BOOT_defconfig P4080DS_SRIO_PCIE_BOOT_defconfig P5020DS_defconfig P5020DS_NAND_defconfig P5020DS_SDCARD_defconfig P5020DS_SPIFLASH_defconfig P5020DS_SRIO_PCIE_BOOT_defconfig platinum_picon_defconfig platinum_titanium_defconfig pogo_e02_defconfig qemu_mips64_defconfig qemu_mips64el_defconfig qemu_mips_defconfig qemu_mipsel_defconfig qemu-ppce500_defconfig r7780mp_defconfig sansa_fuze_plus_defconfig sbc8349_defconfig sbc8349_PCI_33_defconfig sbc8349_PCI_66_defconfig sbc8548_defconfig sbc8548_PCI_33_defconfig sbc8548_PCI_33_PCIE_defconfig sbc8548_PCI_66_defconfig sbc8548_PCI_66_PCIE_defconfig sbc8641d_defconfig sc_sps_1_defconfig secomx6quq7_defconfig sh7752evb_defconfig sh7753evb_defconfig sh7757lcr_defconfig sh7763rdp_defconfig spear300_defconfig spear300_nand_defconfig spear300_usbtty_defconfig spear300_usbtty_nand_defconfig spear310_defconfig spear310_nand_defconfig spear310_pnor_defconfig spear310_usbtty_defconfig spear310_usbtty_nand_defconfig spear310_usbtty_pnor_defconfig spear320_defconfig spear320_nand_defconfig spear320_pnor_defconfig spear320_usbtty_defconfig spear320_usbtty_nand_defconfig spear320_usbtty_pnor_defconfig spear600_defconfig spear600_nand_defconfig spear600_usbtty_defconfig spear600_usbtty_nand_defconfig strider_con_defconfig strider_con_dp_defconfig strider_cpu_defconfig strider_cpu_dp_defconfig suvd3_defconfig T1023RDB_defconfig T1023RDB_NAND_defconfig T1023RDB_SDCARD_defconfig T1023RDB_SPIFLASH_defconfig T1024QDS_DDR4_defconfig T1024QDS_defconfig T1024QDS_NAND_defconfig T1024QDS_SDCARD_defconfig T1024QDS_SPIFLASH_defconfig T1040D4RDB_defconfig T1040D4RDB_NAND_defconfig T1040D4RDB_SDCARD_defconfig T1040D4RDB_SPIFLASH_defconfig T1040QDS_DDR4_defconfig T1040QDS_defconfig T1040RDB_defconfig T1040RDB_NAND_defconfig T1040RDB_SDCARD_defconfig T1040RDB_SPIFLASH_defconfig T1042RDB_defconfig T1042RDB_PI_defconfig T1042RDB_PI_NAND_defconfig T1042RDB_PI_SDCARD_defconfig T1042RDB_PI_SPIFLASH_defconfig T2080RDB_SRIO_PCIE_BOOT_defconfig T2081QDS_defconfig T2081QDS_NAND_defconfig T2081QDS_SDCARD_defconfig T2081QDS_SPIFLASH_defconfig T2081QDS_SRIO_PCIE_BOOT_defconfig T4160QDS_defconfig T4160QDS_NAND_defconfig T4160QDS_SDCARD_defconfig T4160RDB_defconfig T4240QDS_defconfig T4240QDS_NAND_defconfig T4240QDS_SDCARD_defconfig T4240QDS_SRIO_PCIE_BOOT_defconfig tao3530_defconfig ti814x_evm_defconfig titanium_defconfig TQM834x_defconfig tqma6dl_mba6_mmc_defconfig tqma6dl_mba6_spi_defconfig tqma6q_mba6_mmc_defconfig tqma6q_mba6_spi_defconfig tqma6s_mba6_mmc_defconfig tqma6s_mba6_spi_defconfig tqma6s_wru4_mmc_defconfig tricorder_defconfig tricorder_flash_defconfig ts4600_defconfig ts4800_defconfig tuge1_defconfig tuxx1_defconfig TWR-P1025_defconfig UCP1020_defconfig usbarmory_defconfig vct_platinumavc_defconfig vct_platinumavc_onenand_defconfig vct_platinumavc_onenand_small_defconfig vct_platinumavc_small_defconfig vct_platinum_defconfig vct_platinum_onenand_defconfig vct_platinum_onenand_small_defconfig vct_platinum_small_defconfig vct_premium_defconfig vct_premium_onenand_defconfig vct_premium_onenand_small_defconfig vct_premium_small_defconfig ve8313_defconfig vexpress_ca15_tc2_defconfig vexpress_ca5x2_defconfig vexpress_ca9x4_defconfig vme8349_defconfig warp_defconfig wb45n_defconfig wb50n_defconfig woodburn_defconfig woodburn_sd_defconfig x600_defconfig xfi3_defconfig xpedite517x_defconfig xpedite520x_defconfig xpedite537x_defconfig xpedite550x_defconfig zmx25_defconfig _______________________________________________
NXP Engineers are working on migration of NXP powerpc platforms like B4, BSC913x, C29X, P1010, P102x, P2041,P3041, P4080, P5020, P1025, T102x, T104x, T208x, T4160, T4240, etc series Some Patches are in already in review and are dependent on feature merger of https://patchwork.ozlabs.org/project/uboot/list/?series=129069&state=*
Please don’t remove them.
Thanks for the update. We won't drop these platforms at this time.
participants (6)
-
Heinrich Schuchardt -
Heinrich Schuchardt -
Lukasz Majewski -
Marek Vasut -
Priyanka Jain -
Tom Rini