[U-Boot] [PATCH 0/2] dm: Complete CONFIG_BLK migration
Adam Ford
aford173 at gmail.com
Fri Jul 13 19:18:36 UTC 2018
On Fri, Jul 13, 2018 at 10:43 AM Adam Ford <aford173 at gmail.com> wrote:
>
> On Fri, Jul 13, 2018 at 10:23 AM Lukasz Majewski <lukma at denx.de> wrote:
> >
> > On Fri, 13 Jul 2018 16:53:53 +0200
> > Marek Vasut <marex at denx.de> wrote:
> >
> > > On 07/13/2018 03:34 PM, Adam Ford wrote:
> > > > On Fri, Jun 29, 2018 at 3:21 PM Adam Ford <aford173 at gmail.com>
> > > > wrote:
> > > >>
> > > >> On Fri, Jun 29, 2018 at 2:09 PM Tom Rini <trini at konsulko.com>
> > > >> wrote:
> > > >>>
> > > >>> On Thu, Jun 28, 2018 at 09:30:19PM -0500, Derald D. Woods wrote:
> > > >>>> On Thu, Jun 28, 2018 at 10:47:36AM -0500, Adam Ford wrote:
> > > >>>>> On Wed, Jun 27, 2018 at 4:41 PM Tom Rini <trini at konsulko.com>
> > > >>>>> wrote:
> > > >>>>>>
> > > >>>>>> On Sat, Jun 23, 2018 at 07:59:30AM -0600, Simon Glass wrote:
> > > >>>>>>> The time has come to migrate all boards to use CONFIG_BLK.
> > > >>>>>>> This series is just a test to see what boards would have to
> > > >>>>>>> be removed if we required CONFIG_BLK, as we plan to after the
> > > >>>>>>> next release.
> > > >>>>>>>
> > > >>>>>>> This should help maintainers see what is impacted.
> > > >>>>>>>
> > > >>>>>>> Hopefully maintainers will be able to convert their boards
> > > >>>>>>> over in the next month so we we can avoid having to remove
> > > >>>>>>> any boards.
> > > >>>>>>>
> > > >>>>>>> The goal is to have all boards use driver model. But so far,
> > > >>>>>>> we do allow CONFIG_DM to not be defined.
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> For 'Force BLK', here is the buildman output showing failed
> > > >>>>>>> boards and the relatively small number of command errors:
> > > >>>>>>>
> > > >>>>>>> 03: Force BLK
> > > >>>>>>> mips: + pic32mzdask
> > > >>>>>>> arm: + mixtile_loftq colibri_imx6_nospl sniper
> > > >>>>>>> omap3_zoom1 tbs2910 Mele_A1000G_quad am335x_igep003x
> > > >>>>>>> mx6ul_14x14_evk mk802_a10s am43xx_hs_evm devkit3250
> > > >>>>>>> pcm051_rev3 am57xx_hs_evm Empire_electronix_m712 Auxtek-T003
> > > >>>>>>> pcm058 zc5202 am335x_shc am335x_shc_ict Hummingbird_A31
> > > >>>>>>> vining_2000 am335x_evm_usbspl ot1200_spl igep00x0 Mele_I7
> > > >>>>>>> Wobo_i5 r7-tv-dongle liteboard omap3_overo am335x_boneblack
> > > >>>>>>> evb-ast2500 warp7 gwventana_gw5904 cairo A13-OLinuXinoM
> > > >>>>>>> mccmon6_sd apalis_imx6_nospl_it wandboard birdland_bav335a
> > > >>>>>>> colibri_imx7 colibri_imx6 inet_q972 xpress_spl
> > > >>>>>>> stm32f429-evaluation udoo_neo igep0032 Mele_M9 A13-OLinuXino
> > > >>>>>>> inet98v_rev2 A10s-OLinuXino-M riotboard snapper9260
> > > >>>>>>> am43xx_evm pfla02 mx6qsabrelite apalis_imx6_nospl_com
> > > >>>>>>> s5p_goni colibri_pxa270 snapper9g20 Yones_Toptech_BS1078_V2
> > > >>>>>>> am335x_shc_sdboot_prompt k2g_hs_evm cl-som-imx7
> > > >>>>>>> am335x_shc_sdboot vf610twr_nand stm32f469-discovery
> > > >>>>>>> am335x_evm_nor mx53cx9020 Empire_electronix_d709 vf610twr
> > > >>>>>>> cm_t43 pengwyn stm32f746-disco Sinovoip_BPI_M2
> > > >>>>>>> Sinovoip_BPI_M3 Sinlinx_SinA31s pico-imx7d am43xx_evm_rtconly
> > > >>>>>>> LicheePi_Zero pcm051_rev1 mccmon6_nor mx6sabreauto
> > > >>>>>>> display5_factory am335x_shc_prompt gwventana_nand
> > > >>>>>>> Bananapi_M2_Ultra Auxtek-T004 tbs_a711 cm_t335 h8_homlet_v2
> > > >>>>>>> Colombus am43xx_evm_usbhost_boot chiliboard am335x_baltos
> > > >>>>>>> colibri_vf mx6ul_9x9_evk kp_imx6q_tpc bk4r1 udoo
> > > >>>>>>> difrnce_dit4350 am335x_evm_norboot UTOO_P66 iNet_86VS
> > > >>>>>>> marsboard MSI_Primo81 apalis_imx6 bananapi_m2_berry
> > > >>>>>>> xilinx_zynqmp_r5 birdland_bav335b am43xx_evm_qspiboot
> > > >>>>>>> CSQ_CS908 Ampe_A76 kp_imx53 am335x_evm_spiboot
> > > >>>>>>> Cubietruck_plus k2g_evm mx6sabresd omap3_logic pepper
> > > >>>>>>> colorfly_e708_q1 pcm052 gwventana_emmc am335x_boneblack_vboot
> > > >>>>>>> am335x_shc_netboot xpress ot1200 cgtqmx6eval zc5601
> > > >>>>>>> devkit8000 dh_imx6 mx6cuboxi am57xx_evm am335x_sl50
> > > >>>>>>> q8_a13_tablet sksimx6
> > > >>>>>>>
> > > >>>>>>> microblaze: + microblaze-generic
> > > >>>>>>> powerpc: + P1010RDB-PA_36BIT_NOR_SECBOOT
> > > >>>>>>> BSC9132QDS_SDCARD_DDRCLK100_SECURE
> > > >>>>>>> P1010RDB-PB_SPIFLASH_SECBOOT T1024QDS_DDR4_SECURE_BOOT
> > > >>>>>>> controlcenterd_36BIT_SDCARD
> > > >>>>>>> BSC9132QDS_SDCARD_DDRCLK133_SECURE
> > > >>>>>>> P1010RDB-PA_SPIFLASH_SECBOOT BSC9132QDS_NAND_DDRCLK133_SECURE
> > > >>>>>>> P1010RDB-PA_36BIT_SPIFLASH_SECBOOT P2041RDB_SECURE_BOOT
> > > >>>>>>> P5020DS_NAND_SECURE_BOOT P1010RDB-PB_36BIT_NOR_SECBOOT
> > > >>>>>>> BSC9132QDS_NOR_DDRCLK100_SECURE P3041DS_SECURE_BOOT
> > > >>>>>>> T1042D4RDB_SECURE_BOOT T1042RDB_SECURE_BOOT
> > > >>>>>>> T4240QDS_SECURE_BOOT P1010RDB-PB_36BIT_SPIFLASH_SECBOOT
> > > >>>>>>> P1010RDB-PB_NAND_SECBOOT BSC9132QDS_SPIFLASH_DDRCLK100_SECURE
> > > >>>>>>> P3041DS_NAND_SECURE_BOOT T4160QDS_SECURE_BOOT
> > > >>>>>>> T2080RDB_SECURE_BOOT B4860QDS_SECURE_BOOT P4080DS_SECURE_BOOT
> > > >>>>>>> T2080QDS_SECURE_BOOT P5040DS_SECURE_BOOT
> > > >>>>>>> P1010RDB-PB_36BIT_NAND_SECBOOT
> > > >>>>>>> controlcenterd_36BIT_SDCARD_DEVELOP P1010RDB-PA_NAND_SECBOOT
> > > >>>>>>> BSC9132QDS_SPIFLASH_DDRCLK133_SECURE P1010RDB-PA_NOR_SECBOOT
> > > >>>>>>> controlcenterd_TRAILBLAZER_DEVELOP P5020DS_SECURE_BOOT
> > > >>>>>>> T1024QDS_SECURE_BOOT T1040QDS_SECURE_BOOT
> > > >>>>>>> BSC9132QDS_NOR_DDRCLK133_SECURE T1024RDB_SECURE_BOOT
> > > >>>>>>> P5040DS_NAND_SECURE_BOOT P1010RDB-PA_36BIT_NAND_SECBOOT
> > > >>>>>>> T1042RDB_PI_NAND_SECURE_BOOT T1040RDB_SECURE_BOOT
> > > >>>>>>> T1040D4RDB_SECURE_BOOT BSC9132QDS_NAND_DDRCLK100_SECURE
> > > >>>>>>> P1010RDB-PB_NOR_SECBOOT T1023RDB_SECURE_BOOT
> > > >>>>>>> controlcenterd_TRAILBLAZER
> > > >>>>>>
> > > >>>>>> So, how are the maintainers CC'd on this feeling about the
> > > >>>>>> deadline? It was supposed to be 2018.05, but it's looking
> > > >>>>>> like we would enforce it for 2018.09 at this point in time.
> > > >>>>>
> > > >>>>> I looked at the omap3_logic board, and if I turned on the
> > > >>>>> CONFIG_BLK option, some items in USB break.
> > > >>>>>
> > > >>>>> LD drivers/mtd/built-in.o
> > > >>>>> common/usb_storage.c: In function ‘usb_stor_probe_device’:
> > > >>>>> common/usb_storage.c:207:32: error: ‘struct usb_device’ has no
> > > >>>>> member named ‘dev’; did you mean ‘devnum’?
> > > >>>>> data = dev_get_platdata(udev->dev);
> > > >>>>> ^~~
> > > >>>>> devnum
> > > >>>>> common/usb_storage.c:217:34: error: ‘struct usb_device’ has no
> > > >>>>> member named ‘dev’; did you mean ‘devnum’?
> > > >>>>> ret = blk_create_devicef(udev->dev, "usb_storage_blk", str,
> > > >>>>> ^~~
> > > >>>>> devnum
> > > >>>>> CC drivers/mtd/nand/nand.o
> > > >>>>> scripts/Makefile.build:278: recipe for target
> > > >>>>> 'common/usb_storage.o' failed
> > > >>>>>
> > > >>>>> If I turn off the USB stuff and some of the other items
> > > >>>>> dependent on USB, the issues goes away. I wonder if this may
> > > >>>>> be affecting other uses as well.
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>> This is what I see on omap3-evm also.
> > > >>>
> > > >>> It looks like the USB mass storage gadget code needs converting,
> > > >>> to unblock a number of platforms from being converted fully to
> > > >>> BLK.
> > > >>
> > > >> Does this mean the deadline can/will be extended?
> > > >
> > > > gentile nudge. I haven't heard anything on what direction we should
> > > > head. I don't personally have time right now to work on migrating
> > > > the USB Storage driver to CONFIG_BLK, but if it means getting
> > > > kicked out of U-Boot, I'll remove the feature from my board as a
> > > > temporary solution.
> > >
> > > I'd be strongly opposed to kicking out boards based on some ad-hoc
> > > deadline. The deadline should be extended if there aren't resources to
> > > complete the migration.
> > >
> >
> > I can give an example of Odroid XU3....
> >
> > It looked on the beginning as it was missing some USB support, but it
> > tuned out that the root cause is the lack of support for DM_MMC and
> > DM_REGULATOR (which are necessary for CONFIG_BLK).
> >
> > The simple switch to DM_MMC in the case of exynos brings this board
> > unusable as the eMMC/SD card is not working anymore.
>
> For the omap3_logic board, DM_MMC is already enabled, but I enabled
> DM_REGULATOR, however this wasn't sufficient.
>
> I get errors in usb_storage.c
>
> common/usb_storage.c: In function ‘usb_stor_probe_device’:
> common/usb_storage.c:207:32: error: ‘struct usb_device’ has no member
> named ‘dev’; did you mean ‘devnum’?
> data = dev_get_platdata(udev->dev);
> ^~~
> devnum
> common/usb_storage.c:217:34: error: ‘struct usb_device’ has no member
> named ‘dev’; did you mean ‘devnum’?
> ret = blk_create_devicef(udev->dev, "usb_storage_blk", str,
> ^~~
> devnum
> scripts/Makefile.build:278: recipe for target 'common/usb_storage.o' failed
>
> From a stock omap3_logic_defconfig, if I enable CONFIG_BLK and disable
> CONFIG_USB_STORAGE and it builds and loads successfully. So I think
> seems like we might have some different issues going based on
> different platforms.
I investigated this a bit further. The Mass storage driver is
assuming that when CONFIG_BLK that DM_USB is also present. Enabling
DM_USB fixes the USB Storage build error, but then breaks USB. I
looked through the USB drivers, and it appears as if the glue for
OMAP2+ (excluding am33x) hasn't been updated for DM_USB, so I guess
it's more the platform's driver.
adam
>
> adam
>
> >
> >
> > 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-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
More information about the U-Boot
mailing list