[PATCH 16/25] arm: Remove gwventana boards

[Tim Harvey]

On Mon, Feb 22, 2021 at 9:40 AM Tom Rini <trini at konsulko.com> wrote:
>
> 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.

Tom,

Actually, on the imx8mm-venice board I was working on (patches
submitted but not yet applied) I tried to use dm-SPL and I didn't run
into a code size limit, I ran into a memory limit. On that board just
like the ventana boards we have an i2c based eeprom that contains the
specific board model which dictates the dtb to use. The documentation
I found in U-Boot mentioned that if you need to switch dt's at runtime
you use dm_uninit() followed by dm_init_and_scan() on the new dt and
what happens there is that for SPL dm_uninit() ends up not freeing any
memory thus during the binding in dm_init_and_scan() you will run out
of memory available for your devices. I tried to work around this by
resetting the malloc pointer but then ran into something else and it
was at that time I realized that I just needed to let go of using dm
in the SPL.

I can look at it again after getting the rest of the patches applied.

Tim

>
> > > 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