From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Harvey Date: Mon, 22 Feb 2021 09:24:22 -0800 Subject: [PATCH 16/25] arm: Remove gwventana boards In-Reply-To: <20210217183519.GA10169@bill-the-cat> References: <20210209130317.14883-1-trini@konsulko.com> <20210209130317.14883-16-trini@konsulko.com> <20210210173128.GC10169@bill-the-cat> <20210217183519.GA10169@bill-the-cat> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, Feb 17, 2021 at 10:35 AM Tom Rini 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 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 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 > > > > > Signed-off-by: Tom Rini > > > > > --- > > > > > 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. > > 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, Tim