[PATCH 16/25] arm: Remove gwventana boards

Mon Feb 22 18:40:15 CET 2021

On Mon, Feb 22, 2021 at 09:24:22AM -0800, Tim Harvey wrote:
> On Wed, Feb 17, 2021 at 10:35 AM Tom Rini <trini at konsulko.com> wrote:
> >
> > On Wed, Feb 17, 2021 at 10:26:20AM -0800, Tim Harvey wrote:
> > > On Wed, Feb 10, 2021 at 9:31 AM Tom Rini <trini at konsulko.com> wrote:
> > > >
> > > > On Wed, Feb 10, 2021 at 09:29:44AM -0800, Tim Harvey wrote:
> > > > > On Tue, Feb 9, 2021 at 5:03 AM Tom Rini <trini at konsulko.com> wrote:
> > > > > >
> > > > > > These boards have not been converted to CONFIG_DM_MMC by the deadline of
> > > > > > v2019.04, which is almost two years ago.  In addition there are other DM
> > > > > > migrations it is also missing.  Remove them.
> > > > > >
> > > > > > Cc: Tim Harvey <tharvey at gateworks.com>
> > > > > > Signed-off-by: Tom Rini <trini at konsulko.com>
> > > > > > ---
> > > > > >  arch/arm/mach-imx/mx6/Kconfig               |    1 -
> > > > > >  board/gateworks/gw_ventana/Kconfig          |   28 -
> > > > > >  board/gateworks/gw_ventana/MAINTAINERS      |    8 -
> > > > > >  board/gateworks/gw_ventana/Makefile         |   11 -
> > > > > >  board/gateworks/gw_ventana/README           |  320 ----
> > > > > >  board/gateworks/gw_ventana/common.c         | 1760 -------------------
> > > > > >  board/gateworks/gw_ventana/common.h         |   99 --
> > > > > >  board/gateworks/gw_ventana/eeprom.c         |  266 ---
> > > > > >  board/gateworks/gw_ventana/gsc.c            |  283 ---
> > > > > >  board/gateworks/gw_ventana/gsc.h            |   71 -
> > > > > >  board/gateworks/gw_ventana/gw_ventana.c     | 1381 ---------------
> > > > > >  board/gateworks/gw_ventana/gw_ventana_spl.c |  779 --------
> > > > > >  board/gateworks/gw_ventana/ventana_eeprom.h |  140 --
> > > > > >  configs/gwventana_emmc_defconfig            |  111 --
> > > > > >  configs/gwventana_gw5904_defconfig          |  115 --
> > > > > >  configs/gwventana_nand_defconfig            |  115 --
> > > > > >  include/configs/gw_ventana.h                |  298 ----
> > > > > >  17 files changed, 5786 deletions(-)
> > > > > >  delete mode 100644 board/gateworks/gw_ventana/Kconfig
> > > > > >  delete mode 100644 board/gateworks/gw_ventana/MAINTAINERS
> > > > > >  delete mode 100644 board/gateworks/gw_ventana/Makefile
> > > > > >  delete mode 100644 board/gateworks/gw_ventana/README
> > > > > >  delete mode 100644 board/gateworks/gw_ventana/common.c
> > > > > >  delete mode 100644 board/gateworks/gw_ventana/common.h
> > > > > >  delete mode 100644 board/gateworks/gw_ventana/eeprom.c
> > > > > >  delete mode 100644 board/gateworks/gw_ventana/gsc.c
> > > > > >  delete mode 100644 board/gateworks/gw_ventana/gsc.h
> > > > > >  delete mode 100644 board/gateworks/gw_ventana/gw_ventana.c
> > > > > >  delete mode 100644 board/gateworks/gw_ventana/gw_ventana_spl.c
> > > > > >  delete mode 100644 board/gateworks/gw_ventana/ventana_eeprom.h
> > > > > >  delete mode 100644 configs/gwventana_emmc_defconfig
> > > > > >  delete mode 100644 configs/gwventana_gw5904_defconfig
> > > > > >  delete mode 100644 configs/gwventana_nand_defconfig
> > > > > >  delete mode 100644 include/configs/gw_ventana.h
> > > > > >
> > > > >
> > > > > Tom,
> > > > >
> > > > > I will submit a patchset to convert the gw_ventana IMX6 based boards
> > > > > to DM. I started this effort over a year ago and got stuck at some
> > > > > point but I think I know how to get through that now.
> > > > >
> > > > > I hope to be able to submit something by the end of next week.
> > > >
> > > > Thanks!  Their conversion will help unblock a few of the older
> > > > migrations.
> > >
> > > Tom / Stefano,
> > >
> > > Looking at this again I realize where I got stuck previously trying to
> > > migrate the Gateworks Ventana support to driver-model.
> >
> > Thanks for digging in and summarizing.
> >
> > > 1. I need MULTI_DTB_FIT for raw NAND and the following issues are blocking me:
> > >   a. spl_nand_fit_read() requires the reads to be page-aligned to the
> > > writesize of the NAND device. I have to work through trying to give
> > > the common nand spl code knowledge of the mtd device to get around
> > > this.
> > >   b. spl_nand_fit_read() since 9f6a14c47ff9 ("spl: fit: nand: fix fit
> > > loading in case of bad blocks") which introduces bad block handling
> > > now requires a lot of static defines describing the NAND chip such as
> > > CONFIG_SYS_NAND_BLOCK_SIZE CONFIG_SYS_NAND_BAD_BLOCK_POS and a few
> > > more that I need to get from mtd as well as we support multiple flash
> > > devices that have different geometries. I can wrap that code around an
> > > 'ifdef CONFIG_SYS_NAND_BLOCK_SIZE' to opt out of that feature.
> >
> > Which is all SPL related, right?  It seems so, but to be clear...
> >
> 
> Yes, both issues above are with regards to imx SPL+FIT+NAND.
> Ironically if I could use driver-model for SPL it would make things
> much easier working around what I ran into.
> 
> > > 2. I have a board with an MV88E61XX switch and
> > > drivers/net/phy/mv88e61xx.c and I don't see any driver-model support
> > > for eth switches connected to a phy. This blocks me from using DM_ETH.
> > > I have an unsubmitted patch queued up depending on my imx8mm-venice
> > > series that I think may provide a dm solution for network switches via
> > > DM_ETH_PHY.
> > > 3. I can't use driver model for SPL because of memory constraints: I
> > > need to read the board model from an I2C EEPROM in the SPL and then if
> > > I wanted to use SPL dm I would have to use dm_uninit() followed by
> > > dm_init_and_scan() which doesn't work because dm_uninit() does not
> > > free memory. It seems to me the DM_SPL code needs to implement memory
> > > free.
> > >
> > > The biggest hurdle I see is (3) above and as far as I can tell most if
> > > not all other IMX boards are not using driver model for SPL. If this
> > > is true, then there are a lot of boards out there that haven't been
> > > able to fully swtich to driver model and are getting missed in the
> > > checks because DM_USB, DM_MMC, DM_* are defined for U-boot proper.
> > > That does not help remove legacy code from what I can tell.
> > >
> > > What are your thoughts on the fact that many (majority?) boards are
> > > still using non-dm code for SPL?
> >
> > So, SPL in DM is not a general requirement.  There's some new features
> > in SPL that aren't available without it, but if you aren't using them
> > today, that's not a big problem.
> 
> Ok... I just thought it was strange that there was this big push to
> get all MMC to DM_MMC yet the non-dm mmc code still seems to be needed
> for all the boards using non-dm SPL.

It's this hard problem we're still working to solve.  I'm going to
assume you hit a hard size limit when trying to use DM+SPL.  I'd really
like to see those WIP patches, so that we can see what else needs to
happen to make everything be small enough, but I'd like to see the rest
of the migration happen first, so we can otherwise unblock things.

> > That leaves DM_ETH, which has a deadline of v2020.07 (so just barely
> > past) and since you're on the way to hopefully addressing the general
> > problem, that's great.  My big concern right now is all of the
> > v2019.04/07 deadlines.  If you can address those right now, that's
> > great.
> 
> I should be able to address that. Hopefully I'll have a patch series
> submitted soon.

Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210222/cab291a9/attachment.sig>