[U-Boot] [PATCH 00/93] dm: Move towards completing CONFIG_BLK migration

Tue Nov 20 17:18:17 UTC 2018

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 <trini at konsulko.com> 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 <trini at konsulko.com> wrote:
> >>>>>>>>
> >>>>>>>> On Mon, Nov 19, 2018 at 10:54 AM Simon Glass <sjg at chromium.org> 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: <http://lists.denx.de/pipermail/u-boot/attachments/20181120/ce178f0d/attachment.sig>