dm: Move towards completing CONFIG_BLK migration

Hi Tom,

Quoted 119 lines · Tom Rini

Quoted 118 lines · Stefano Babic

Hi,

Quoted 84 lines · Marek Vasut

Quoted 75 lines · Adam Ford

Quoted 70 lines · Tom Rini

Quoted 45 lines · Marek Vasut

Quoted 36 lines · Adam Ford

Quoted 23 lines · Tom Rini

Quoted 19 lines · Simon Glass

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.

Quoted 1 line

So, send a patch!

Quoted 11 lines

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.

Quoted 7 lines

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.

Quoted 7 lines

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.

Quoted 3 lines

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.

Quoted 7 lines

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.

Quoted 1 line

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.

Quoted 5 lines

Quoted 2 lines

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.

Quoted 4 lines

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.