* [U-Boot] [RFC] Eliminate boards not using CONFIG_DM=y
@ 2019-11-25 23:16 Heinrich Schuchardt
2019-11-26 8:11 ` [U-Boot] [U-Boot-Board-Maintainers] " Marek Vasut
2019-11-29 6:46 ` [U-Boot] [U-Boot-Custodians] " Priyanka Jain
0 siblings, 2 replies; 13+ messages in thread
From: Heinrich Schuchardt @ 2019-11-25 23:16 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [U-Boot-Board-Maintainers] [RFC] Eliminate boards not using CONFIG_DM=y
2019-11-25 23:16 [U-Boot] [RFC] Eliminate boards not using CONFIG_DM=y Heinrich Schuchardt
@ 2019-11-26 8:11 ` Marek Vasut
2019-11-26 16:26 ` [U-Boot] [U-Boot-Custodians] " Tom Rini
2019-11-29 6:46 ` [U-Boot] [U-Boot-Custodians] " Priyanka Jain
1 sibling, 1 reply; 13+ messages in thread
From: Marek Vasut @ 2019-11-26 8:11 UTC (permalink / raw)
To: u-boot
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.
[...]
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] [RFC] Eliminate boards not using CONFIG_DM=y
2019-11-26 8:11 ` [U-Boot] [U-Boot-Board-Maintainers] " Marek Vasut
@ 2019-11-26 16:26 ` Tom Rini
2019-11-26 16:31 ` [U-Boot] [U-Boot-Board-Maintainers] [U-Boot-Custodians] " Lukasz Majewski
2019-11-26 16:47 ` [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] " Marek Vasut
0 siblings, 2 replies; 13+ messages in thread
From: Tom Rini @ 2019-11-26 16:26 UTC (permalink / raw)
To: u-boot
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?
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191126/d16b82a2/attachment.sig>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [U-Boot-Board-Maintainers] [U-Boot-Custodians] [RFC] Eliminate boards not using CONFIG_DM=y
2019-11-26 16:26 ` [U-Boot] [U-Boot-Custodians] " Tom Rini
@ 2019-11-26 16:31 ` Lukasz Majewski
2019-11-26 16:56 ` Tom Rini
2019-11-26 16:47 ` [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] " Marek Vasut
1 sibling, 1 reply; 13+ messages in thread
From: Lukasz Majewski @ 2019-11-26 16:31 UTC (permalink / raw)
To: u-boot
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 at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191126/505afe36/attachment.sig>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] [RFC] Eliminate boards not using CONFIG_DM=y
2019-11-26 16:26 ` [U-Boot] [U-Boot-Custodians] " Tom Rini
2019-11-26 16:31 ` [U-Boot] [U-Boot-Board-Maintainers] [U-Boot-Custodians] " Lukasz Majewski
@ 2019-11-26 16:47 ` Marek Vasut
2019-11-26 16:52 ` Tom Rini
1 sibling, 1 reply; 13+ messages in thread
From: Marek Vasut @ 2019-11-26 16:47 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] [RFC] Eliminate boards not using CONFIG_DM=y
2019-11-26 16:47 ` [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] " Marek Vasut
@ 2019-11-26 16:52 ` Tom Rini
2019-11-26 17:07 ` Marek Vasut
0 siblings, 1 reply; 13+ messages in thread
From: Tom Rini @ 2019-11-26 16:52 UTC (permalink / raw)
To: u-boot
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?
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191126/069470ed/attachment.sig>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [U-Boot-Board-Maintainers] [U-Boot-Custodians] [RFC] Eliminate boards not using CONFIG_DM=y
2019-11-26 16:31 ` [U-Boot] [U-Boot-Board-Maintainers] [U-Boot-Custodians] " Lukasz Majewski
@ 2019-11-26 16:56 ` Tom Rini
0 siblings, 0 replies; 13+ messages in thread
From: Tom Rini @ 2019-11-26 16:56 UTC (permalink / raw)
To: u-boot
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.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191126/eea82dee/attachment.sig>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] [RFC] Eliminate boards not using CONFIG_DM=y
2019-11-26 16:52 ` Tom Rini
@ 2019-11-26 17:07 ` Marek Vasut
2019-11-28 6:22 ` Heinrich Schuchardt
0 siblings, 1 reply; 13+ messages in thread
From: Marek Vasut @ 2019-11-26 17:07 UTC (permalink / raw)
To: u-boot
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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] [RFC] Eliminate boards not using CONFIG_DM=y
2019-11-26 17:07 ` Marek Vasut
@ 2019-11-28 6:22 ` Heinrich Schuchardt
2019-11-28 9:40 ` Marek Vasut
0 siblings, 1 reply; 13+ messages in thread
From: Heinrich Schuchardt @ 2019-11-28 6:22 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] [RFC] Eliminate boards not using CONFIG_DM=y
2019-11-28 6:22 ` Heinrich Schuchardt
@ 2019-11-28 9:40 ` Marek Vasut
2019-11-28 16:51 ` Tom Rini
0 siblings, 1 reply; 13+ messages in thread
From: Marek Vasut @ 2019-11-28 9:40 UTC (permalink / raw)
To: u-boot
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 ?
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] [RFC] Eliminate boards not using CONFIG_DM=y
2019-11-28 9:40 ` Marek Vasut
@ 2019-11-28 16:51 ` Tom Rini
0 siblings, 0 replies; 13+ messages in thread
From: Tom Rini @ 2019-11-28 16:51 UTC (permalink / raw)
To: u-boot
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.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191128/b22c6067/attachment.sig>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [U-Boot-Custodians] [RFC] Eliminate boards not using CONFIG_DM=y
2019-11-25 23:16 [U-Boot] [RFC] Eliminate boards not using CONFIG_DM=y Heinrich Schuchardt
2019-11-26 8:11 ` [U-Boot] [U-Boot-Board-Maintainers] " Marek Vasut
@ 2019-11-29 6:46 ` Priyanka Jain
2019-11-29 15:18 ` Tom Rini
1 sibling, 1 reply; 13+ messages in thread
From: Priyanka Jain @ 2019-11-29 6:46 UTC (permalink / raw)
To: u-boot
>-----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 at lists.denx.de; u-boot-board-
>maintainers at 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>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [U-Boot-Custodians] [RFC] Eliminate boards not using CONFIG_DM=y
2019-11-29 6:46 ` [U-Boot] [U-Boot-Custodians] " Priyanka Jain
@ 2019-11-29 15:18 ` Tom Rini
0 siblings, 0 replies; 13+ messages in thread
From: Tom Rini @ 2019-11-29 15:18 UTC (permalink / raw)
To: u-boot
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 at lists.denx.de; u-boot-board-
> >maintainers at 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.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191129/a91c0f53/attachment.sig>
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2019-11-29 15:18 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-25 23:16 [U-Boot] [RFC] Eliminate boards not using CONFIG_DM=y Heinrich Schuchardt
2019-11-26 8:11 ` [U-Boot] [U-Boot-Board-Maintainers] " Marek Vasut
2019-11-26 16:26 ` [U-Boot] [U-Boot-Custodians] " Tom Rini
2019-11-26 16:31 ` [U-Boot] [U-Boot-Board-Maintainers] [U-Boot-Custodians] " Lukasz Majewski
2019-11-26 16:56 ` Tom Rini
2019-11-26 16:47 ` [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] " Marek Vasut
2019-11-26 16:52 ` Tom Rini
2019-11-26 17:07 ` Marek Vasut
2019-11-28 6:22 ` Heinrich Schuchardt
2019-11-28 9:40 ` Marek Vasut
2019-11-28 16:51 ` Tom Rini
2019-11-29 6:46 ` [U-Boot] [U-Boot-Custodians] " Priyanka Jain
2019-11-29 15:18 ` Tom Rini
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.