[PATCH 16/25] arm: Remove gwventana boards
Simon Glass
sjg at chromium.org
Tue Mar 2 18:25:00 CET 2021
Hi Tom,
On Tue, 23 Feb 2021 at 10:39, Tim Harvey <tharvey at gateworks.com> wrote:
>
> 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.
In SPL at least, you need to use the correct devicetree when initing
driver model. The free() function is a nop in SPL.
So do you have multiple DTs in the SPL image, and select from one
using the EEPROM? Can you not use TPL to handle this, so that it can
load SPL with the correct devicetree? That might be easier. Also doing
this all in SPL is not compatible with of-platdata-inst, which (at
present at least) binds all devices at build time using a single DT.
The problem with resetting the malloc pointer is that there may be
other allocations before or driver model. If you must avoid TPL, one
option might be to implement a way to record the malloc pointer when
dm_init() is called and after it finishes. Then add a dm_reinit()
function which makes sure the malloc() pointer has not since moved,
resets to the original and sets up DM again. This could only be used
immediately after DM init, though.
But honestly I am not a fan of reiniting DM twice. At minimum you
should make sure that the base devicetree has only the EEPROM device,
i.e. just enough to get that up and running. So I think TPL is better.
Another option is to read from the EEPROM in pre-DM code. Not very
nice or easy though. I think that might be a rabbit hole.
>
> 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
Regards,
Simon
More information about the U-Boot
mailing list