From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Tue, 20 Nov 2018 12:18:17 -0500 Subject: [U-Boot] [PATCH 00/93] dm: Move towards completing CONFIG_BLK migration In-Reply-To: <30a17d00-ab9a-a944-cd87-5d92bd48d55a@denx.de> References: <20181119155413.158098-1-sjg@chromium.org> <20181119215427.GP11247@bill-the-cat> <064625fe-250e-98d7-adf1-b315f8313598@gmail.com> <20181120145547.GT11247@bill-the-cat> <30a17d00-ab9a-a944-cd87-5d92bd48d55a@denx.de> Message-ID: <20181120171817.GE11247@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, Nov 20, 2018 at 05:27:03PM +0100, Stefano Babic wrote: > Hi Tom, > > On 20/11/18 15:55, Tom Rini wrote: > > On Tue, Nov 20, 2018 at 12:00:13PM +0100, Stefano Babic wrote: > >> Hi, > >> > >> On 19/11/18 23:06, Marek Vasut wrote: > >>> On 11/19/2018 11:02 PM, Adam Ford wrote: > >>>> On Mon, Nov 19, 2018 at 3:54 PM Tom Rini wrote: > >>>>> > >>>>> On Mon, Nov 19, 2018 at 10:32:01PM +0100, Marek Vasut wrote: > >>>>>> On 11/19/2018 08:45 PM, Adam Ford wrote: > >>>>>>> On Mon, Nov 19, 2018 at 12:36 PM Tom Rini wrote: > >>>>>>>> > >>>>>>>> On Mon, Nov 19, 2018 at 10:54 AM Simon Glass wrote: > >>>>>>>>> > >>>>>>>>> All boards should now be migrated to use CONFIG_BLK. This series removes > >>>>>>>>> those with build problems using this option. > >>>>>>>>> > >>>>>>>>> If maintainers want to keep these boards in they should send a patch in > >>>>>>>>> the next week or two. Otherwise the board will be removed in the next > >>>>>>>>> release, and will need to be added and re-reviewed later. > >>>>>>>>> > >>>>>>>>> The goal is to have all boards use driver model. But so far, we do allow > >>>>>>>>> CONFIG_DM to not be defined. > >>>>>>>>> > >>>>>>>>> PLEASE NOTE: This is not an easy process. It is possible that your board > >>>>>>>>> does work, or works with only minor changes. Please try to understand that > >>>>>>>>> the removal of a board is not done because people don't like your board. > >>>>>>>>> In fact the board might have been the first one I used when trying out > >>>>>>>>> U-Boot! It's just that we expect maintainers to keep up with the migration > >>>>>>>>> to driver model which has been running now for 4 years. It just isn't > >>>>>>>>> possible for a few people to migrate and test hundreds of boards. > >>>>>>>>> > >>>>>>>>> So, send a patch! > >>>>>>>> > >>>>>>>> OK, so with the intention of "need to light a fire", consider the fire > >>>>>>>> lit! But, I think v2 of this series needs to: > >>>>>>>> - Address the bug that's been noted of you checking on "DM_BLK" when > >>>>>>>> it's really just "BLK". > >>>>>>>> - Do a test build with BLK just being unconditional now. For example, > >>>>>>>> you're deleting the am335x_evm family but it builds fine with BLK > >>>>>>>> being enabled now. I even gave it a run time test via test.py and > >>>>>>>> we're fine. So, I think a new run where you see what fails to build > >>>>>>>> with BLK enabled by default now is in order to come up with a new > >>>>>>>> delete list. > >>>>>>>> > >>>>>>> > >>>>>>> When we were migrating toward GCC 6, we introduced a warning message > >>>>>>> that was displayed at build indicating older versions of GCC would be > >>>>>>> unsupported, and GCC 6 would become a requirement. The > >>>>>>> CONFIG_DM_I2C_COMPAT generates a build warning and suggests that it be > >>>>>>> removed. I would like to propose that in the future, when setting > >>>>>>> deadlines, we insert something into the build mechanism that generates > >>>>>>> a warning to tell people that something is going to happen. > >>>>>> > >>>>>> I agree, that sounds good. > >>>>>> > >>>>>> I am extremely unhappy by how Simon decided, unilaterally, some > >>>>>> arbitrary deadline, told pretty much no one about that deadline and then > >>>>>> put a knife on many peoples' throats by sending out this series which > >>>>>> removes boards that are actively used and maintained, demanding they be > >>>>>> converted right this instant. > >>>>> > >>>>> OK, lets step back for a moment. Part of the problem is that yes, we > >>>>> (I) never found a good way to make a big scary build warning happen. > >>>>> But, lets look at https://patchwork.ozlabs.org/patch/798309/ for a > >>>>> moment, which is when we set this deadline, and we had a good bit of > >>>>> discussion about related issues to make it happen. > >>>>> > >>>>> I also know that around the v2018.05 release I said, in public, but no I > >>>>> can't find a link right this moment, that we were pushing off a little > >>>>> bit on dropping _everything_ right then as there was basically some > >>>>> fairly important / widely used USB stuff that hadn't been converted yet > >>>>> (which has since been, I think, otherwise am335x_evm & co wouldn't have > >>>>> been happy?). I know I did since I can see in the archives a number of > >>>>> series where maintainers did a bunch of changes to various platforms / > >>>>> SoCs to turn on BLK right then. > >>>>> > >>>>> So, no, I don't want to drop a bunch of platforms _right_now_. But we > >>>>> really need to see what doesn't link anymore with BLK forced on, and > >>>>> plan from there. > >>>> > >>>> I remember the discussion, but it seems rather arbitrary for one > >>>> person to unilaterally start deleting boards. I think a more > >>>> appropriate approach would be to start a dialog instead of deleting > >>>> boards and then giving people a fairly short notice to respond - > >>>> especially this close to the US Thanksgiving holiday, several > >>>> religious holidays and New Years. Many people have planed time off > >>>> and/or end-of-year deadlines to hit without getting an abrupt suprise. > >>> > >>> ACK > >> > >> > >> I fully agree with Marek and Adam, but I have also some other technical > >> points related to i.MX6. > >> > >> I agree to move to new and better code, but this should not drop > >> important features that are appreciated by customers. Up now, U-Boot as > >> project was pretty conservative, trying t osupport as far as it is > >> possible even older architectures (MPC 88x, for example). > >> > >> On i.MX6, a feature is to have a single U-Boot binary (SPL + U-Boot) > >> running for more variants (Quad / Dual / Solo) of the SOC. This is done > >> with run time detection in code (SPL) - macros are provide to make the > >> work easy (it is, currently). There are plenty of boards doing this (all > >> listed by Simon for removal). This is common if the board has a SOM, and > >> of course the SOM is sold in different variants with different prices. > >> > >> If I understand well, moving to CONFIG_BLK means enabling CONFIG_DM_MMC > >> and this requires to set a DTS. But a DT is compiled by DTC, that means > >> we have a DT for each variant of the SOC. This forbids to have a single > >> binary and we need different binaries, one for each variant. We lose an > >> important feature, at least for some boards. Agree that having DT is > >> nice, but this should not drop what customer are asking. > >> > >> I know there are some improvement in TI code to get the root node in DT > >> and then load from it. Anyway, specially for i.MX6 solo, we are quite > >> running out of space in SRAM, mainly due to other required features. And > >> having multiple DTB with CONFIG_MULTI_DTB_FIT seems to work just if we > >> have no SPL. > >> > >> So first, it looks like that the issue is not so trivial as it was, and > >> second a technical solution must be searched for that. > > > > Yes, this is a useful feature on i.MX lines and we need to figure out > > how to keep it. > > Right, fully agree. > > > Perhaps we'll need some combination of > > CONFIG_SPL_FIT_LOAD (and board_fit_config_name_match) along with perhaps > > introducing a TPL to i.MX where we can get away with doing whatever we > > need to do, to init DRAM and have enough space to put SPL and U-Boot? > > I am just figuring out how we can do. One other aspect introducing > another stage as TPL could be the increased boot time, even if I guess > it is not much. However, there are some applications in automotive that > are very "sensible" to any increment in boot time. I would hope that it's no more a change in measurable boot time than anything else that changes in the code base, but that might also be the point when it's time to tune the build into a single config (as I would _hope_ any run-time differences between board revs can be pushed back to OS time or at least full U-Boot rather than initial steps but DRAM config could complicate that). -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: