On Mon, Feb 22, 2021 at 9:40 AM Tom Rini <tr...@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 <tr...@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 <tr...@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 <tr...@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 <thar...@gateworks.com>
> > > > > > > Signed-off-by: Tom Rini <tr...@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
