dm: Move towards completing CONFIG_BLK migration

This board has not been converted to CONFIG_DM_BLK by the deadline. Remove it.

Signed-off-by Simon Glass <[email protected]>

This board has not been converted to CONFIG_DM_BLK by the deadline. Remove it.

Signed-off-by Simon Glass <[email protected]>

This board has not been converted to CONFIG_DM_BLK by the deadline. Remove it.

Signed-off-by Simon Glass <[email protected]>

---

  arch/arm/mach-omap2/Kconfig   |   1 -
  board/BuR/brppt1/Kconfig      |  15 --
  board/BuR/brppt1/MAINTAINERS  |   8 --
  board/BuR/brppt1/Makefile     |  12 --
  board/BuR/brppt1/board.c      | 190 -------------------------
  board/BuR/brppt1/config.mk    |  36 -----
  board/BuR/brppt1/mux.c        | 253 ----------------------------------
  configs/brppt1_mmc_defconfig  |  95 -------------
  configs/brppt1_nand_defconfig |  99 -------------
  configs/brppt1_spi_defconfig  | 109 ---------------
  include/configs/brppt1.h      | 214 ----------------------------
  11 files changed, 1032 deletions(-)

delete mode 100644 board/BuR/brppt1/Kconfig delete mode 100644 board/BuR/brppt1/MAINTAINERS delete mode 100644 board/BuR/brppt1/Makefile delete mode 100644 board/BuR/brppt1/board.c delete mode 100644 board/BuR/brppt1/config.mk delete mode 100644 board/BuR/brppt1/mux.c delete mode 100644 configs/brppt1_mmc_defconfig delete mode 100644 configs/brppt1_nand_defconfig delete mode 100644 configs/brppt1_spi_defconfig delete mode 100644 include/configs/brppt1.h

Quoted 18 lines · Simon Glass

This board has not been converted to CONFIG_DM_BLK by the deadline. Remove it.

Signed-off-by Simon Glass <[email protected]>

---

  arch/arm/mach-omap2/Kconfig   |   1 -
  board/BuR/brppt1/Kconfig      |  15 --
  board/BuR/brppt1/MAINTAINERS  |   8 --
  board/BuR/brppt1/Makefile     |  12 --
  board/BuR/brppt1/board.c      | 190 -------------------------
  board/BuR/brppt1/config.mk    |  36 -----
  board/BuR/brppt1/mux.c        | 253 ----------------------------------
  configs/brppt1_mmc_defconfig  |  95 -------------
  configs/brppt1_nand_defconfig |  99 -------------
  configs/brppt1_spi_defconfig  | 109 ---------------
  include/configs/brppt1.h      | 214 ----------------------------
  11 files changed, 1032 deletions(-)

Quoted 10 lines

delete mode 100644 board/BuR/brppt1/Kconfig delete mode 100644 board/BuR/brppt1/MAINTAINERS delete mode 100644 board/BuR/brppt1/Makefile delete mode 100644 board/BuR/brppt1/board.c delete mode 100644 board/BuR/brppt1/config.mk delete mode 100644 board/BuR/brppt1/mux.c delete mode 100644 configs/brppt1_mmc_defconfig delete mode 100644 configs/brppt1_nand_defconfig delete mode 100644 configs/brppt1_spi_defconfig delete mode 100644 include/configs/brppt1.h

NAK.
As the speakers before i didn't notice that deadline.
I will have a look into next few days and provide a patch for converting if necessary.

This board has not been converted to CONFIG_DM_BLK by the deadline. Remove it.

Signed-off-by Simon Glass <[email protected]>

All boards should now be migrated to use CONFIG_BLK. This series removes those with build problems using this option.

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!

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!

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.

Thanks!

--
Tom

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.

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 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.

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.

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.

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.

Thank you very much to the many maintainers who have met the deadline and converted their boards. Apologies to those who converted, and still got this email.

(massively trimmed cc list, leaving the current sunxi custodians and Hans who is a fellow emeritus custodian)

Quoted 3 lines · Simon Glass

Thank you very much to the many maintainers who have met the deadline and converted their boards. Apologies to those who converted, and still got this email.

TBH I'm still unsure why I was copied. I stepped down as sunxi custodian ages ago. I checked in u-boot.git and I am listed in board/sunxi/MAINTAINERS for Cubieboard and Mele M5, but neither of those (nor any sunxi board generally) seems to be the subject of this series. My address doesn't appear anywhere else in the repo.

Do I (or the sunxi folks) need to be doing anything?

Or has ./scripts/get_maintainer.pl just been overzealous somewhere?

Hi,

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.

Yes, I need to ignore warnings. I saw some boards trying to call non-DM functions and assumed they all did, but they were just DTC warnings. I'll see if I can figure out how to turn those off.

So if you didn't know about CONFIG_BLK migration from the June email, hopefully you see this one :-) If your board is already converted, please don't worry, I will try to get this right in the v2 series, which hopefully will be much smaller.

Thank you very much to the many maintainers who have met the deadline and converted their boards. Apologies to those who converted, and still got this email.

And please read my note in the cover letter.

Hi again,

Quoted 87 lines · Simon Glass

Hi,

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.

Yes, I need to ignore warnings. I saw some boards trying to call non-DM functions and assumed they all did, but they were just DTC warnings. I'll see if I can figure out how to turn those off.

So if you didn't know about CONFIG_BLK migration from the June email, hopefully you see this one :-) If your board is already converted, please don't worry, I will try to get this right in the v2 series, which hopefully will be much smaller.

Quoted 5 lines

Thank you very much to the many maintainers who have met the deadline and converted their boards. Apologies to those who converted, and still got this email.

And please read my note in the cover letter.

I went back to what I did many months ago - simply checking for CONFIG_BLK=y being enabled (using buildman -D).

Unfortunately, for ARM, this results in 517 out of 833 boards being removed!

This seems worse that the approach used in this series, checking whether boards build with CONFIG_BLK forced on.

I do have another idea. I got a very large number of bounces from maintainer emails from this series. I could collect all of those and figure out which boards don't have maintainers with working emails, and then remove them first.

The best solution IMO is for maintainers to take a little time to convert boards over. I don't think this is a lot of work, particularly if the board uses drivers which are already converted.

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.

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.

--
Tom

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.

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 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.

ACK

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.

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.

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.

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.

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 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.

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?

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.

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.

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.

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!

Simon Glass (93):
Add a simple script to remove boards
dm: mmc: Use CONFIG_IS_ENABLED to check for BLK
solidrun: Correct typo in MAINTAINERS
arm: Remove s32v234evb board
arm: Remove ls1043ardb_sdcard_SECURE_BOOT board
arm: Remove ls1046ardb_sdcard_SECURE_BOOT board
arm: Remove colibri_imx6_nospl board
arm: Remove guruplug board
arm: Remove sniper board
arm: Remove omap3_zoom1 board
arm: Remove sksimx6 board
arm: Remove tbs2910 board
arm: Remove theadorable_debug board
arm: Remove devkit3250 board
arm: Remove pcm051_rev3 board
arm: Remove ds109 board
arm: Remove pcm058 board
arm: Remove am335x_shc_ict board
arm: Remove vining_2000 board
arm: Remove cm_t43 board
arm: Remove igep00x0 board
arm: Remove sheevaplug board
arm: Remove omap3_overo board
arm: Remove am335x_boneblack board
arm: Remove warp7 board
arm: Remove gwventana_gw5904 board
arm: Remove cairo board
arm: Remove pico-hobbit-imx7d board
arm: Remove mccmon6_sd board
arm: Remove apalis_imx6_nospl_it board
arm: Remove wandboard board
arm: Remove birdland_bav335a board
arm: Remove gurnard board
arm: Remove xpress_spl board
arm: Remove udoo_neo board
arm: Remove nas220 board
arm: Remove am335x_pdu001 board
arm: Remove snapper9260 board
arm: Remove pfla02 board
arm: Remove colibri_pxa270 board
arm: Remove work_92105 board
arm: Remove omap3_pandora board
arm: Remove cl-som-imx7 board
arm: Remove devkit8000 board
arm: Remove pengwyn board
arm: Remove dreamplug board
arm: Remove mx6sabreauto board
arm: Remove imx6q_logic board
arm: Remove zc5202 board
arm: Remove imx6dl_mamoj board
arm: Remove omap3_logic_somlv board
arm: Remove cm_t335 board
arm: Remove liteboard board
arm: Remove am43xx_evm_usbhost_boot board
arm: Remove chiliboard board
arm: Remove am335x_baltos board
arm: Remove kp_imx6q_tpc board
arm: Remove lsxhl board
arm: Remove udoo board
arm: Remove marsboard board
arm: Remove mx6sabresd board
arm: Remove dh_imx6 board
arm: Remove vinco board
arm: Remove ls1021atwr_sdcard_ifc_SECURE_BOOT board
arm: Remove mx6cuboxi board
arm: Remove ot1200 board
arm: Remove socfpga_stratix10 board
arm: Remove am65x_evm_a53 board
arm: Remove ap143 board
arm: Remove ap121 board
arm: Remove imgtec_xilfpga board
arm: Remove socfpga_de0_nano_soc board
arm: Remove clearfog board
arm: Remove socfpga_arria10 board
arm: Remove omap3_beagle board
arm: Remove helios4 board
arm: Remove socfpga_socrates board
arm: Remove socfpga_sr1500 board
arm: Remove ls1021aiot_sdcard board
arm: Remove socfpga_de10_nano board
arm: Remove socfpga_dbm_soc1 board
arm: Remove socfpga_de1_soc board
arm: Remove socfpga_sockit board
arm: Remove dns325 board
arm: Remove socfpga_is1 board
arm: Remove brppt1_mmc board
arm: Remove db-mv784mp-gp board
arm: Remove socfpga_arria5 board
arm: Remove socfpga_vining_fpga board
arm: Remove dra7xx_evm and dra7xx_hs_evm boards
dm: Enable CONFIG_BLK
dm: Update driver-model migration schedule for CONFIG_BLK
RFC: dm: Force CONFIG_BLK for all boards with DM

 arch/arm/Kconfig                              |   13 -
 arch/arm/cpu/arm926ejs/lpc32xx/Kconfig        |    2 -
 arch/arm/cpu/armv8/s32v234/Makefile           |    6 -
 arch/arm/cpu/armv8/s32v234/cpu.c              |   98 -
 arch/arm/cpu/armv8/s32v234/cpu.h              |    7 -
 arch/arm/cpu/armv8/s32v234/generic.c          |  349 ---
 arch/arm/dts/imx6dl-mamoj-u-boot.dtsi         |   14 -
 arch/arm/dts/imx6dl-mamoj.dts                 |  225 --
 arch/arm/include/asm/arch-am33xx/chilisom.h   |   14 -
 arch/arm/include/asm/arch-s32v234/clock.h     |   33 -
 arch/arm/include/asm/arch-s32v234/ddr.h       |  156 -
 arch/arm/include/asm/arch-s32v234/imx-regs.h  |  328 ---
 arch/arm/include/asm/arch-s32v234/lpddr2.h    |   74 -
 .../include/asm/arch-s32v234/mc_cgm_regs.h    |  253 --
 .../arm/include/asm/arch-s32v234/mc_me_regs.h |  198 --
 .../include/asm/arch-s32v234/mc_rgm_regs.h    |   30 -
 arch/arm/include/asm/arch-s32v234/mmdc.h      |   88 -
 arch/arm/include/asm/arch-s32v234/siul.h      |  149 -
 arch/arm/mach-at91/Kconfig                    |    3 -
 arch/arm/mach-imx/mx6/Kconfig                 |   24 -
 arch/arm/mach-imx/mx7/Kconfig                 |    3 -
 arch/arm/mach-k3/Kconfig                      |    1 -
 arch/arm/mach-kirkwood/Kconfig                |    7 -
 arch/arm/mach-omap2/Kconfig                   |    5 -
 arch/arm/mach-omap2/am33xx/chilisom.c         |  184 --
 arch/arm/mach-omap2/omap3/Kconfig             |    9 -
 arch/arm/mach-omap2/omap5/Kconfig             |    1 -
 arch/mips/Kconfig                             |    1 -
 arch/mips/mach-ath79/Kconfig                  |    2 -
 board/BuR/brppt1/Kconfig                      |   15 -
 board/BuR/brppt1/MAINTAINERS                  |    8 -
 board/BuR/brppt1/Makefile                     |   12 -
 board/BuR/brppt1/board.c                      |  190 --
 board/BuR/brppt1/config.mk                    |   36 -
 board/BuR/brppt1/mux.c                        |  253 --
 board/Marvell/db-mv784mp-gp/MAINTAINERS       |    6 -
 board/Marvell/db-mv784mp-gp/Makefile          |    5 -
 board/Marvell/db-mv784mp-gp/db-mv784mp-gp.c   |  117 -
 board/Marvell/dreamplug/Kconfig               |   12 -
 board/Marvell/dreamplug/MAINTAINERS           |    6 -
 board/Marvell/dreamplug/Makefile              |   10 -
 board/Marvell/dreamplug/dreamplug.c           |  135 -
 board/Marvell/dreamplug/dreamplug.h           |   25 -
 board/Marvell/dreamplug/kwbimage.cfg          |  145 -
 board/Marvell/guruplug/Kconfig                |   12 -
 board/Marvell/guruplug/MAINTAINERS            |    6 -
 board/Marvell/guruplug/Makefile               |    7 -
 board/Marvell/guruplug/guruplug.c             |  138 -
 board/Marvell/guruplug/guruplug.h             |   22 -
 board/Marvell/guruplug/kwbimage.cfg           |  144 -
 board/Marvell/sheevaplug/Kconfig              |   12 -
 board/Marvell/sheevaplug/MAINTAINERS          |    6 -
 board/Marvell/sheevaplug/Makefile             |    7 -
 board/Marvell/sheevaplug/kwbimage.cfg         |  144 -
 board/Marvell/sheevaplug/sheevaplug.c         |  133 -
 board/Marvell/sheevaplug/sheevaplug.h         |   24 -
 board/Seagate/nas220/Kconfig                  |   12 -
 board/Seagate/nas220/MAINTAINERS              |    6 -
 board/Seagate/nas220/Makefile                 |    7 -
 board/Seagate/nas220/kwbimage.cfg             |  151 -
 board/Seagate/nas220/nas220.c                 |  118 -
 board/Synology/ds109/Kconfig                  |   12 -
 board/Synology/ds109/MAINTAINERS              |    6 -
 board/Synology/ds109/Makefile                 |    7 -
 board/Synology/ds109/ds109.c                  |  176 --
 board/Synology/ds109/ds109.h                  |   43 -
 board/Synology/ds109/kwbimage.cfg             |  150 -
 board/Synology/ds109/openocd.cfg              |  115 -
 board/altera/arria10-socdk/Kconfig            |   18 -
 board/altera/arria10-socdk/MAINTAINERS        |    7 -
 board/altera/arria10-socdk/Makefile           |    5 -
 board/altera/arria10-socdk/socfpga.c          |    6 -
 board/altera/arria5-socdk/MAINTAINERS         |    7 -
 board/altera/arria5-socdk/Makefile            |    7 -
 board/altera/arria5-socdk/qts/iocsr_config.h  |  695 -----
 board/altera/arria5-socdk/qts/pinmux_config.h |  218 --
 board/altera/arria5-socdk/qts/pll_config.h    |   84 -
 board/altera/arria5-socdk/qts/sdram_config.h  |  342 ---
 board/altera/arria5-socdk/socfpga.c           |    5 -
 board/altera/cyclone5-socdk/MAINTAINERS       |   12 -
 board/altera/cyclone5-socdk/Makefile          |    7 -
 .../altera/cyclone5-socdk/qts/iocsr_config.h  |  659 -----
 .../altera/cyclone5-socdk/qts/pinmux_config.h |  218 --
 board/altera/cyclone5-socdk/qts/pll_config.h  |   84 -
 .../altera/cyclone5-socdk/qts/sdram_config.h  |  344 ---
 board/altera/cyclone5-socdk/socfpga.c         |    5 -
 board/altera/stratix10-socdk/MAINTAINERS      |    7 -
 board/altera/stratix10-socdk/Makefile         |    7 -
 board/altera/stratix10-socdk/socfpga.c        |    7 -
 board/bachmann/ot1200/Kconfig                 |   12 -
 board/bachmann/ot1200/MAINTAINERS             |    6 -
 board/bachmann/ot1200/Makefile                |   11 -
 board/bachmann/ot1200/README                  |   20 -
 board/bachmann/ot1200/mx6q_4x_mt41j128.cfg    |  154 -
 board/bachmann/ot1200/ot1200.c                |  356 ---
 board/bachmann/ot1200/ot1200_spl.c            |  151 -
 board/birdland/bav335x/Kconfig                |   23 -
 board/birdland/bav335x/Makefile               |   11 -
 board/birdland/bav335x/README                 |   31 -
 board/birdland/bav335x/board.c                |  429 ---
 board/birdland/bav335x/board.h                |   58 -
 board/birdland/bav335x/mux.c                  |  190 --
 board/birdland/bav335x/u-boot.lds             |  115 -
 board/bluewater/gurnard/Kconfig               |   12 -
 board/bluewater/gurnard/MAINTAINERS           |    6 -
 board/bluewater/gurnard/Makefile              |    9 -
 board/bluewater/gurnard/gurnard.c             |  423 ---
 board/bluewater/gurnard/splash_logo.h         | 2619 -----------------
 board/bluewater/snapper9260/Kconfig           |   12 -
 board/bluewater/snapper9260/MAINTAINERS       |    7 -
 board/bluewater/snapper9260/Makefile          |    9 -
 board/bluewater/snapper9260/snapper9260.c     |  151 -
 board/bosch/shc/Kconfig                       |   87 -
 board/bosch/shc/MAINTAINERS                   |   11 -
 board/bosch/shc/Makefile                      |    8 -
 board/bosch/shc/README                        |  114 -
 board/bosch/shc/board.c                       |  647 ----
 board/bosch/shc/board.h                       |  186 --
 board/bosch/shc/mux.c                         |  260 --
 board/bticino/mamoj/Kconfig                   |   12 -
 board/bticino/mamoj/MAINTAINERS               |   10 -
 board/bticino/mamoj/Makefile                  |    8 -
 board/bticino/mamoj/README                    |  124 -
 board/bticino/mamoj/mamoj.c                   |   26 -
 board/bticino/mamoj/spl.c                     |  171 --
 board/buffalo/lsxl/Kconfig                    |   12 -
 board/buffalo/lsxl/MAINTAINERS                |    7 -
 board/buffalo/lsxl/Makefile                   |    6 -
 board/buffalo/lsxl/README                     |  139 -
 board/buffalo/lsxl/kwbimage-lschl.cfg         |  211 --
 board/buffalo/lsxl/kwbimage-lsxhl.cfg         |  211 --
 board/buffalo/lsxl/lsxl.c                     |  279 --
 board/buffalo/lsxl/lsxl.h                     |   58 -
 board/ccv/xpress/Kconfig                      |   12 -
 board/ccv/xpress/MAINTAINERS                  |    7 -
 board/ccv/xpress/Makefile                     |    6 -
 board/ccv/xpress/imximage.cfg                 |  175 --
 board/ccv/xpress/spl.c                        |  117 -
 board/ccv/xpress/xpress.c                     |  336 ---
 board/compulab/cl-som-imx7/Kconfig            |   28 -
 board/compulab/cl-som-imx7/MAINTAINERS        |    6 -
 board/compulab/cl-som-imx7/Makefile           |   17 -
 board/compulab/cl-som-imx7/cl-som-imx7.c      |  331 ---
 board/compulab/cl-som-imx7/common.c           |   45 -
 board/compulab/cl-som-imx7/common.h           |   31 -
 board/compulab/cl-som-imx7/mux.c              |  141 -
 board/compulab/cl-som-imx7/spl.c              |  210 --
 board/compulab/cm_t335/Kconfig                |   15 -
 board/compulab/cm_t335/MAINTAINERS            |    6 -
 board/compulab/cm_t335/Makefile               |    8 -
 board/compulab/cm_t335/cm_t335.c              |  162 -
 board/compulab/cm_t335/mux.c                  |  116 -
 board/compulab/cm_t335/spl.c                  |  113 -
 board/compulab/cm_t335/u-boot.lds             |  110 -
 board/compulab/cm_t43/Kconfig                 |   15 -
 board/compulab/cm_t43/MAINTAINERS             |    6 -
 board/compulab/cm_t43/Makefile                |   11 -
 board/compulab/cm_t43/board.h                 |   11 -
 board/compulab/cm_t43/cm_t43.c                |  164 --
 board/compulab/cm_t43/mux.c                   |  142 -
 board/compulab/cm_t43/spl.c                   |  134 -
 board/d-link/dns325/Kconfig                   |   12 -
 board/d-link/dns325/MAINTAINERS               |    6 -
 board/d-link/dns325/Makefile                  |   11 -
 board/d-link/dns325/dns325.c                  |  131 -
 board/d-link/dns325/dns325.h                  |   31 -
 board/d-link/dns325/kwbimage.cfg              |  190 --
 board/dhelectronics/dh_imx6/Kconfig           |   12 -
 board/dhelectronics/dh_imx6/MAINTAINERS       |    7 -
 board/dhelectronics/dh_imx6/Makefile          |    9 -
 board/dhelectronics/dh_imx6/dh_imx6.c         |  431 ---
 board/dhelectronics/dh_imx6/dh_imx6_spl.c     |  591 ----
 board/ebv/socrates/MAINTAINERS                |    6 -
 board/ebv/socrates/Makefile                   |    7 -
 board/ebv/socrates/qts/iocsr_config.h         |  659 -----
 board/ebv/socrates/qts/pinmux_config.h        |  218 --
 board/ebv/socrates/qts/pll_config.h           |   84 -
 board/ebv/socrates/qts/sdram_config.h         |  343 ---
 board/ebv/socrates/socfpga.c                  |    5 -
 board/eets/pdu001/Kconfig                     |   50 -
 board/eets/pdu001/MAINTAINERS                 |    6 -
 board/eets/pdu001/Makefile                    |   13 -
 board/eets/pdu001/README                      |   35 -
 board/eets/pdu001/board.c                     |  275 --
 board/eets/pdu001/board.h                     |   37 -
 board/eets/pdu001/mux.c                       |  119 -
 board/el/el6x/Kconfig                         |   25 -
 board/el/el6x/MAINTAINERS                     |    8 -
 board/el/el6x/Makefile                        |    5 -
 board/el/el6x/el6x.c                          |  631 ----
 board/embest/mx6boards/Kconfig                |   12 -
 board/embest/mx6boards/MAINTAINERS            |    7 -
 board/embest/mx6boards/Makefile               |    7 -
 board/embest/mx6boards/mx6boards.c            |  610 ----
 board/freescale/ls1021aiot/Kconfig            |   17 -
 board/freescale/ls1021aiot/MAINTAINERS        |    7 -
 board/freescale/ls1021aiot/Makefile           |    7 -
 board/freescale/ls1021aiot/README             |   58 -
 board/freescale/ls1021aiot/dcu.c              |   46 -
 board/freescale/ls1021aiot/ls1021aiot.c       |  249 --
 board/freescale/ls1021aiot/ls102xa_pbi.cfg    |   14 -
 board/freescale/ls1021aiot/ls102xa_rcw_sd.cfg |   27 -
 board/freescale/ls1021aiot/psci.S             |   27 -
 board/freescale/ls1021atwr/Kconfig            |   17 -
 board/freescale/ls1021atwr/MAINTAINERS        |   15 -
 board/freescale/ls1021atwr/Makefile           |    9 -
 board/freescale/ls1021atwr/README             |  115 -
 board/freescale/ls1021atwr/dcu.c              |   46 -
 board/freescale/ls1021atwr/ls1021atwr.c       |  764 -----
 board/freescale/ls1021atwr/ls102xa_pbi.cfg    |   12 -
 .../ls1021atwr/ls102xa_rcw_sd_ifc.cfg         |    8 -
 .../ls1021atwr/ls102xa_rcw_sd_qspi.cfg        |    8 -
 board/freescale/ls1021atwr/psci.S             |   24 -
 board/freescale/ls1043ardb/Kconfig            |   41 -
 board/freescale/ls1043ardb/MAINTAINERS        |   16 -
 board/freescale/ls1043ardb/Makefile           |   10 -
 board/freescale/ls1043ardb/README             |   54 -
 board/freescale/ls1043ardb/cpld.c             |  173 --
 board/freescale/ls1043ardb/cpld.h             |   45 -
 board/freescale/ls1043ardb/ddr.c              |  238 --
 board/freescale/ls1043ardb/ddr.h              |  116 -
 board/freescale/ls1043ardb/eth.c              |   76 -
 board/freescale/ls1043ardb/ls1043ardb.c       |  221 --
 board/freescale/ls1043ardb/ls1043ardb_pbi.cfg |   14 -
 .../ls1043ardb/ls1043ardb_rcw_nand.cfg        |    7 -
 .../ls1043ardb/ls1043ardb_rcw_sd.cfg          |    7 -
 board/freescale/ls1046ardb/Kconfig            |   31 -
 board/freescale/ls1046ardb/MAINTAINERS        |   20 -
 board/freescale/ls1046ardb/Makefile           |   10 -
 board/freescale/ls1046ardb/README             |   76 -
 board/freescale/ls1046ardb/cpld.c             |  166 --
 board/freescale/ls1046ardb/cpld.h             |   49 -
 board/freescale/ls1046ardb/ddr.c              |  119 -
 board/freescale/ls1046ardb/ddr.h              |   62 -
 board/freescale/ls1046ardb/eth.c              |  127 -
 board/freescale/ls1046ardb/ls1046ardb.c       |  182 --
 board/freescale/ls1046ardb/ls1046ardb_pbi.cfg |   22 -
 .../ls1046ardb/ls1046ardb_qspi_pbi.cfg        |   26 -
 .../ls1046ardb/ls1046ardb_rcw_emmc.cfg        |    7 -
 .../ls1046ardb/ls1046ardb_rcw_qspi.cfg        |    7 -
 .../ls1046ardb/ls1046ardb_rcw_sd.cfg          |    7 -
 board/freescale/mx6sabreauto/Kconfig          |   12 -
 board/freescale/mx6sabreauto/MAINTAINERS      |    7 -
 board/freescale/mx6sabreauto/Makefile         |    7 -
 board/freescale/mx6sabreauto/README           |   82 -
 board/freescale/mx6sabreauto/mx6sabreauto.c   | 1099 -------
 board/freescale/mx6sabresd/Kconfig            |   12 -
 board/freescale/mx6sabresd/MAINTAINERS        |    6 -
 board/freescale/mx6sabresd/Makefile           |    7 -
 board/freescale/mx6sabresd/README             |  114 -
 board/freescale/mx6sabresd/mx6sabresd.c       | 1064 -------
 board/freescale/s32v234evb/Kconfig            |   23 -
 board/freescale/s32v234evb/MAINTAINERS        |    8 -
 board/freescale/s32v234evb/Makefile           |    9 -
 board/freescale/s32v234evb/clock.c            |  343 ---
 board/freescale/s32v234evb/lpddr2.c           |  136 -
 board/freescale/s32v234evb/s32v234evb.c       |  182 --
 board/freescale/s32v234evb/s32v234evb.cfg     |   28 -
 board/gateworks/gw_ventana/Kconfig            |   25 -
 board/gateworks/gw_ventana/MAINTAINERS        |    8 -
 board/gateworks/gw_ventana/Makefile           |   11 -
 board/gateworks/gw_ventana/README             |  320 --
 board/gateworks/gw_ventana/common.c           | 1422 ---------
 board/gateworks/gw_ventana/common.h           |   98 -
 board/gateworks/gw_ventana/eeprom.c           |  238 --
 board/gateworks/gw_ventana/gsc.c              |  274 --
 board/gateworks/gw_ventana/gsc.h              |   70 -
 board/gateworks/gw_ventana/gw_ventana.c       | 1351 ---------
 board/gateworks/gw_ventana/gw_ventana_spl.c   |  691 -----
 board/gateworks/gw_ventana/ventana_eeprom.h   |  133 -
 board/grinn/chiliboard/Kconfig                |   15 -
 board/grinn/chiliboard/MAINTAINERS            |    8 -
 board/grinn/chiliboard/Makefile               |    4 -
 board/grinn/chiliboard/README                 |   31 -
 board/grinn/chiliboard/board.c                |  205 --
 board/grinn/liteboard/Kconfig                 |   12 -
 board/grinn/liteboard/MAINTAINERS             |    6 -
 board/grinn/liteboard/Makefile                |    4 -
 board/grinn/liteboard/README                  |   31 -
 board/grinn/liteboard/board.c                 |  286 --
 board/imgtec/xilfpga/Kconfig                  |   15 -
 board/imgtec/xilfpga/MAINTAINERS              |    6 -
 board/imgtec/xilfpga/Makefile                 |    7 -
 board/imgtec/xilfpga/README                   |   55 -
 board/imgtec/xilfpga/xilfpga.c                |   23 -
 board/is1/MAINTAINERS                         |    6 -
 board/is1/Makefile                            |    5 -
 board/is1/qts/iocsr_config.h                  |  659 -----
 board/is1/qts/pinmux_config.h                 |  218 --
 board/is1/qts/pll_config.h                    |   84 -
 board/is1/qts/sdram_config.h                  |  343 ---
 board/is1/socfpga.c                           |    4 -
 board/isee/igep00x0/Kconfig                   |   12 -
 board/isee/igep00x0/MAINTAINERS               |    7 -
 board/isee/igep00x0/Makefile                  |   10 -
 board/isee/igep00x0/common.c                  |   67 -
 board/isee/igep00x0/igep00x0.c                |  258 --
 board/isee/igep00x0/igep00x0.h                |  127 -
 board/isee/igep00x0/spl.c                     |   63 -
 board/k+p/kp_imx6q_tpc/Kconfig                |   12 -
 board/k+p/kp_imx6q_tpc/MAINTAINERS            |    6 -
 board/k+p/kp_imx6q_tpc/Makefile               |    9 -
 board/k+p/kp_imx6q_tpc/kp_imx6q_tpc.c         |  301 --
 board/k+p/kp_imx6q_tpc/kp_imx6q_tpc_spl.c     |  337 ---
 board/kobol/helios4/MAINTAINERS               |    6 -
 board/kobol/helios4/Makefile                  |    5 -
 board/kobol/helios4/README                    |   46 -
 board/kobol/helios4/helios4.c                 |  163 -
 board/l+g/vinco/Kconfig                       |   12 -
 board/l+g/vinco/MAINTAINERS                   |    6 -
 board/l+g/vinco/Makefile                      |    1 -
 board/l+g/vinco/vinco.c                       |  212 --
 board/lg/sniper/Kconfig                       |   12 -
 board/lg/sniper/MAINTAINERS                   |    6 -
 board/lg/sniper/Makefile                      |    7 -
 board/lg/sniper/sniper.c                      |  189 --
 board/lg/sniper/sniper.h                      |  364 ---
 board/liebherr/mccmon6/Kconfig                |   12 -
 board/liebherr/mccmon6/MAINTAINERS            |    7 -
 board/liebherr/mccmon6/Makefile               |    6 -
 board/liebherr/mccmon6/mccmon6.c              |  489 ---
 board/liebherr/mccmon6/mon6_imximage_nor.cfg  |    8 -
 board/liebherr/mccmon6/mon6_imximage_sd.cfg   |    8 -
 board/liebherr/mccmon6/spl.c                  |  298 --
 board/logicpd/imx6/Kconfig                    |   12 -
 board/logicpd/imx6/MAINTAINERS                |    6 -
 board/logicpd/imx6/Makefile                   |   10 -
 board/logicpd/imx6/README                     |   37 -
 board/logicpd/imx6/imx6logic.c                |  325 --
 board/logicpd/omap3som/Kconfig                |   14 -
 board/logicpd/omap3som/MAINTAINERS            |    9 -
 board/logicpd/omap3som/Makefile               |    6 -
 board/logicpd/omap3som/README                 |   56 -
 board/logicpd/omap3som/omap3logic.c           |  329 ---
 board/logicpd/omap3som/omap3logic.h           |  236 --
 board/logicpd/zoom1/Kconfig                   |   12 -
 board/logicpd/zoom1/MAINTAINERS               |    6 -
 board/logicpd/zoom1/Makefile                  |    6 -
 board/logicpd/zoom1/config.mk                 |   14 -
 board/logicpd/zoom1/zoom1.c                   |  146 -
 board/logicpd/zoom1/zoom1.h                   |  122 -
 board/overo/Kconfig                           |    9 -
 board/overo/MAINTAINERS                       |    6 -
 board/overo/Makefile                          |   10 -
 board/overo/common.c                          |  341 ---
 board/overo/overo.c                           |  420 ---
 board/overo/overo.h                           |  169 --
 board/overo/spl.c                             |   59 -
 board/pandora/Kconfig                         |    9 -
 board/pandora/MAINTAINERS                     |    6 -
 board/pandora/Makefile                        |    6 -
 board/pandora/pandora.c                       |  147 -
 board/pandora/pandora.h                       |  391 ---
 board/phytec/pcm051/Kconfig                   |   15 -
 board/phytec/pcm051/MAINTAINERS               |    7 -
 board/phytec/pcm051/Makefile                  |   11 -
 board/phytec/pcm051/board.c                   |  256 --
 board/phytec/pcm051/board.h                   |   24 -
 board/phytec/pcm051/mux.c                     |  127 -
 board/phytec/pcm058/Kconfig                   |   12 -
 board/phytec/pcm058/MAINTAINERS               |    6 -
 board/phytec/pcm058/Makefile                  |    7 -
 board/phytec/pcm058/README                    |   35 -
 board/phytec/pcm058/pcm058.c                  |  568 ----
 board/phytec/pfla02/Kconfig                   |   18 -
 board/phytec/pfla02/MAINTAINERS               |    6 -
 board/phytec/pfla02/Makefile                  |    7 -
 board/phytec/pfla02/README                    |   24 -
 board/phytec/pfla02/pfla02.c                  |  707 -----
 board/qca/ap121/Kconfig                       |   27 -
 board/qca/ap121/MAINTAINERS                   |    6 -
 board/qca/ap121/Makefile                      |    3 -
 board/qca/ap121/ap121.c                       |   46 -
 board/qca/ap143/Kconfig                       |   27 -
 board/qca/ap143/MAINTAINERS                   |    6 -
 board/qca/ap143/Makefile                      |    3 -
 board/qca/ap143/ap143.c                       |   62 -
 board/quipos/cairo/Kconfig                    |   12 -
 board/quipos/cairo/MAINTAINERS                |    6 -
 board/quipos/cairo/Makefile                   |    6 -
 board/quipos/cairo/cairo.c                    |   98 -
 board/quipos/cairo/cairo.h                    |  318 --
 board/samtec/vining_2000/Kconfig              |   12 -
 board/samtec/vining_2000/MAINTAINERS          |    6 -
 board/samtec/vining_2000/Makefile             |    4 -
 board/samtec/vining_2000/imximage.cfg         |  131 -
 board/samtec/vining_2000/vining_2000.c        |  517 ----
 board/silica/pengwyn/Kconfig                  |   15 -
 board/silica/pengwyn/MAINTAINERS              |    6 -
 board/silica/pengwyn/Makefile                 |   11 -
 board/silica/pengwyn/board.c                  |  201 --
 board/silica/pengwyn/board.h                  |   14 -
 board/silica/pengwyn/mux.c                    |   97 -
 board/sks-kinkel/sksimx6/Kconfig              |   11 -
 board/sks-kinkel/sksimx6/MAINTAINERS          |    6 -
 board/sks-kinkel/sksimx6/Makefile             |    2 -
 board/sks-kinkel/sksimx6/sksimx6.c            |  425 ---
 board/solidrun/clearfog/MAINTAINERS           |    6 -
 board/solidrun/clearfog/Makefile              |    5 -
 board/solidrun/clearfog/README                |   51 -
 board/solidrun/clearfog/clearfog.c            |  141 -
 board/solidrun/mx6cuboxi/Kconfig              |   12 -
 board/solidrun/mx6cuboxi/MAINTAINERS          |    6 -
 board/solidrun/mx6cuboxi/Makefile             |    7 -
 board/solidrun/mx6cuboxi/README               |   21 -
 board/solidrun/mx6cuboxi/mx6cuboxi.c          |  857 ------
 board/sr1500/MAINTAINERS                      |    6 -
 board/sr1500/Makefile                         |    5 -
 board/sr1500/qts/iocsr_config.h               |  659 -----
 board/sr1500/qts/pinmux_config.h              |  218 --
 board/sr1500/qts/pll_config.h                 |   84 -
 board/sr1500/qts/sdram_config.h               |  343 ---
 board/sr1500/socfpga.c                        |   26 -
 board/tbs/tbs2910/Kconfig                     |   18 -
 board/tbs/tbs2910/MAINTAINERS                 |    6 -
 board/tbs/tbs2910/Makefile                    |    5 -
 board/tbs/tbs2910/tbs2910.c                   |  454 ---
 board/tbs/tbs2910/tbs2910.cfg                 |  114 -
 board/technexion/pico-imx7d/Kconfig           |   15 -
 board/technexion/pico-imx7d/MAINTAINERS       |   16 -
 board/technexion/pico-imx7d/Makefile          |    4 -
 board/technexion/pico-imx7d/README            |   64 -
 board/technexion/pico-imx7d/pico-imx7d.c      |  315 --
 board/technexion/pico-imx7d/spl.c             |  122 -
 board/theadorable/MAINTAINERS                 |    6 -
 board/theadorable/Makefile                    |    6 -
 board/theadorable/fpga.c                      |  178 --
 board/theadorable/theadorable.c               |  336 ---
 board/theadorable/theadorable.h               |   11 -
 board/ti/am335x/Kconfig                       |   24 -
 board/ti/am335x/MAINTAINERS                   |   12 -
 board/ti/am335x/Makefile                      |   11 -
 board/ti/am335x/README                        |  205 --
 board/ti/am335x/board.c                       | 1073 -------
 board/ti/am335x/board.h                       |   97 -
 board/ti/am335x/mux.c                         |  413 ---
 board/ti/am335x/u-boot.lds                    |  164 --
 board/ti/am43xx/Kconfig                       |   17 -
 board/ti/am43xx/MAINTAINERS                   |   11 -
 board/ti/am43xx/Makefile                      |   11 -
 board/ti/am43xx/board.c                       |  957 ------
 board/ti/am43xx/board.h                       |   62 -
 board/ti/am43xx/mux.c                         |  153 -
 board/ti/am65x/Kconfig                        |   52 -
 board/ti/am65x/MAINTAINERS                    |    7 -
 board/ti/am65x/Makefile                       |    8 -
 board/ti/am65x/README                         |  211 --
 board/ti/am65x/evm.c                          |   68 -
 board/ti/beagle/Kconfig                       |   12 -
 board/ti/beagle/MAINTAINERS                   |    6 -
 board/ti/beagle/Makefile                      |    7 -
 board/ti/beagle/beagle.c                      |  591 ----
 board/ti/beagle/beagle.h                      |  545 ----
 board/ti/beagle/led.c                         |   71 -
 board/ti/dra7xx/Kconfig                       |   14 -
 board/ti/dra7xx/MAINTAINERS                   |    7 -
 board/ti/dra7xx/Makefile                      |    6 -
 board/ti/dra7xx/README                        |   26 -
 board/ti/dra7xx/evm.c                         | 1202 --------
 board/ti/dra7xx/mux_data.h                    | 1121 -------
 board/timll/devkit3250/Kconfig                |   12 -
 board/timll/devkit3250/MAINTAINERS            |    6 -
 board/timll/devkit3250/Makefile               |    7 -
 board/timll/devkit3250/devkit3250.c           |   80 -
 board/timll/devkit3250/devkit3250_spl.c       |   67 -
 board/timll/devkit8000/Kconfig                |   12 -
 board/timll/devkit8000/MAINTAINERS            |    6 -
 board/timll/devkit8000/Makefile               |    9 -
 board/timll/devkit8000/README                 |   15 -
 board/timll/devkit8000/devkit8000.c           |  206 --
 board/timll/devkit8000/devkit8000.h           |  359 ---
 .../toradex/apalis_imx6/1066mhz_4x128mx16.cfg |   47 -
 .../toradex/apalis_imx6/1066mhz_4x256mx16.cfg |   47 -
 board/toradex/apalis_imx6/Kconfig             |   55 -
 board/toradex/apalis_imx6/MAINTAINERS         |    9 -
 board/toradex/apalis_imx6/Makefile            |    5 -
 board/toradex/apalis_imx6/apalis_imx6.c       | 1236 --------
 board/toradex/apalis_imx6/apalis_imx6q.cfg    |   33 -
 board/toradex/apalis_imx6/clocks.cfg          |   41 -
 board/toradex/apalis_imx6/ddr-setup.cfg       |   96 -
 board/toradex/apalis_imx6/do_fuse.c           |   97 -
 board/toradex/apalis_imx6/pf0100.c            |  230 --
 board/toradex/apalis_imx6/pf0100.h            |   52 -
 board/toradex/apalis_imx6/pf0100_otp.inc      |  190 --
 .../toradex/colibri_imx6/800mhz_2x64mx16.cfg  |   58 -
 .../toradex/colibri_imx6/800mhz_4x64mx16.cfg  |   58 -
 board/toradex/colibri_imx6/Kconfig            |   44 -
 board/toradex/colibri_imx6/MAINTAINERS        |    8 -
 board/toradex/colibri_imx6/Makefile           |    5 -
 board/toradex/colibri_imx6/clocks.cfg         |   41 -
 board/toradex/colibri_imx6/colibri_imx6.c     | 1121 -------
 board/toradex/colibri_imx6/colibri_imx6.cfg   |   37 -
 board/toradex/colibri_imx6/ddr-setup.cfg      |   97 -
 board/toradex/colibri_imx6/do_fuse.c          |   97 -
 board/toradex/colibri_imx6/pf0100.c           |  212 --
 board/toradex/colibri_imx6/pf0100.h           |   52 -
 board/toradex/colibri_imx6/pf0100_otp.inc     |  188 --
 board/toradex/colibri_pxa270/Kconfig          |   23 -
 board/toradex/colibri_pxa270/MAINTAINERS      |    6 -
 board/toradex/colibri_pxa270/Makefile         |    7 -
 board/toradex/colibri_pxa270/colibri_pxa270.c |  138 -
 board/udoo/Kconfig                            |    9 -
 board/udoo/MAINTAINERS                        |    6 -
 board/udoo/Makefile                           |    5 -
 board/udoo/README                             |   21 -
 board/udoo/neo/Kconfig                        |   12 -
 board/udoo/neo/MAINTAINERS                    |    7 -
 board/udoo/neo/Makefile                       |    4 -
 board/udoo/neo/neo.c                          |  595 ----
 board/udoo/udoo.c                             |  271 --
 board/udoo/udoo_spl.c                         |  254 --
 board/vscom/baltos/Kconfig                    |   15 -
 board/vscom/baltos/MAINTAINERS                |    6 -
 board/vscom/baltos/Makefile                   |   11 -
 board/vscom/baltos/README                     |    1 -
 board/vscom/baltos/board.c                    |  493 ----
 board/vscom/baltos/board.h                    |   34 -
 board/vscom/baltos/mux.c                      |  125 -
 board/vscom/baltos/u-boot.lds                 |  128 -
 board/wandboard/Kconfig                       |    9 -
 board/wandboard/MAINTAINERS                   |    6 -
 board/wandboard/Makefile                      |    5 -
 board/wandboard/README                        |   39 -
 board/wandboard/spl.c                         |  425 ---
 board/wandboard/wandboard.c                   |  559 ----
 board/warp7/Kconfig                           |   23 -
 board/warp7/MAINTAINERS                       |    7 -
 board/warp7/Makefile                          |    4 -
 board/warp7/README                            |   63 -
 board/warp7/imximage.cfg                      |   98 -
 board/warp7/warp7.c                           |  237 --
 board/work-microwave/work_92105/Kconfig       |   24 -
 board/work-microwave/work_92105/MAINTAINERS   |    6 -
 board/work-microwave/work_92105/Makefile      |   10 -
 board/work-microwave/work_92105/README        |   91 -
 board/work-microwave/work_92105/work_92105.c  |   76 -
 .../work_92105/work_92105_display.c           |  348 ---
 .../work_92105/work_92105_display.h           |   13 -
 .../work_92105/work_92105_spl.c               |   84 -
 configs/am335x_baltos_defconfig               |   65 -
 configs/am335x_boneblack_defconfig            |   51 -
 configs/am335x_boneblack_vboot_defconfig      |   56 -
 configs/am335x_evm_defconfig                  |   64 -
 configs/am335x_evm_nor_defconfig              |   53 -
 configs/am335x_evm_norboot_defconfig          |   50 -
 configs/am335x_evm_spiboot_defconfig          |   48 -
 configs/am335x_evm_usbspl_defconfig           |   56 -
 configs/am335x_pdu001_defconfig               |   53 -
 configs/am335x_shc_defconfig                  |   46 -
 configs/am335x_shc_ict_defconfig              |   47 -
 configs/am335x_shc_netboot_defconfig          |   48 -
 configs/am335x_shc_prompt_defconfig           |   45 -
 configs/am335x_shc_sdboot_defconfig           |   47 -
 configs/am335x_shc_sdboot_prompt_defconfig    |   47 -
 configs/am43xx_evm_defconfig                  |   61 -
 configs/am43xx_evm_ethboot_defconfig          |   65 -
 configs/am43xx_evm_qspiboot_defconfig         |   63 -
 configs/am43xx_evm_rtconly_defconfig          |   62 -
 configs/am43xx_evm_usbhost_boot_defconfig     |   75 -
 configs/am43xx_hs_evm_defconfig               |   72 -
 configs/am65x_evm_a53_defconfig               |   71 -
 configs/am65x_evm_r5_defconfig                |   87 -
 configs/ap121_defconfig                       |   60 -
 configs/ap143_defconfig                       |   55 -
 configs/apalis_imx6_defconfig                 |   75 -
 configs/apalis_imx6_nospl_com_defconfig       |   63 -
 configs/apalis_imx6_nospl_it_defconfig        |   63 -
 configs/birdland_bav335a_defconfig            |   67 -
 configs/birdland_bav335b_defconfig            |   67 -
 configs/brppt1_mmc_defconfig                  |   95 -
 configs/brppt1_nand_defconfig                 |   99 -
 configs/brppt1_spi_defconfig                  |  109 -
 configs/cairo_defconfig                       |   39 -
 configs/chiliboard_defconfig                  |   47 -
 configs/cl-som-imx7_defconfig                 |   67 -
 configs/clearfog_defconfig                    |   66 -
 configs/cm_t335_defconfig                     |   51 -
 configs/cm_t43_defconfig                      |   72 -
 configs/colibri_imx6_defconfig                |   73 -
 configs/colibri_imx6_nospl_defconfig          |   61 -
 configs/colibri_pxa270_defconfig              |   40 -
 configs/db-mv784mp-gp_defconfig               |   64 -
 configs/devkit3250_defconfig                  |   48 -
 configs/devkit8000_defconfig                  |   34 -
 configs/dh_imx6_defconfig                     |   63 -
 configs/dns325_defconfig                      |   41 -
 configs/dra7xx_evm_defconfig                  |  102 -
 configs/dra7xx_hs_evm_defconfig               |  101 -
 configs/dreamplug_defconfig                   |   40 -
 configs/ds109_defconfig                       |   38 -
 configs/gurnard_defconfig                     |   38 -
 configs/guruplug_defconfig                    |   43 -
 configs/gwventana_emmc_defconfig              |   88 -
 configs/gwventana_gw5904_defconfig            |   92 -
 configs/gwventana_nand_defconfig              |   91 -
 configs/helios4_defconfig                     |   60 -
 configs/igep0032_defconfig                    |   52 -
 configs/igep00x0_defconfig                    |   53 -
 configs/imgtec_xilfpga_defconfig              |   27 -
 configs/imx6dl_mamoj_defconfig                |   46 -
 configs/imx6q_logic_defconfig                 |   77 -
 configs/kp_imx6q_tpc_defconfig                |   44 -
 configs/liteboard_defconfig                   |   38 -
 configs/ls1021aiot_qspi_defconfig             |   39 -
 configs/ls1021aiot_sdcard_defconfig           |   44 -
 configs/ls1021atwr_nor_SECURE_BOOT_defconfig  |   56 -
 configs/ls1021atwr_nor_defconfig              |   59 -
 configs/ls1021atwr_nor_lpuart_defconfig       |   57 -
 configs/ls1021atwr_qspi_defconfig             |   60 -
 ...s1021atwr_sdcard_ifc_SECURE_BOOT_defconfig |   70 -
 configs/ls1021atwr_sdcard_ifc_defconfig       |   67 -
 configs/ls1021atwr_sdcard_qspi_defconfig      |   70 -
 configs/ls1043ardb_SECURE_BOOT_defconfig      |   51 -
 configs/ls1043ardb_defconfig                  |   49 -
 configs/ls1043ardb_nand_SECURE_BOOT_defconfig |   68 -
 configs/ls1043ardb_nand_defconfig             |   66 -
 .../ls1043ardb_sdcard_SECURE_BOOT_defconfig   |   66 -
 configs/ls1043ardb_sdcard_defconfig           |   64 -
 configs/ls1046ardb_emmc_defconfig             |   63 -
 configs/ls1046ardb_qspi_SECURE_BOOT_defconfig |   49 -
 configs/ls1046ardb_qspi_defconfig             |   49 -
 configs/ls1046ardb_qspi_spl_defconfig         |   66 -
 .../ls1046ardb_sdcard_SECURE_BOOT_defconfig   |   64 -
 configs/ls1046ardb_sdcard_defconfig           |   62 -
 configs/lschlv2_defconfig                     |   42 -
 configs/lsxhl_defconfig                       |   42 -
 configs/marsboard_defconfig                   |   37 -
 configs/mccmon6_nor_defconfig                 |   50 -
 configs/mccmon6_sd_defconfig                  |   51 -
 configs/mx6cuboxi_defconfig                   |   43 -
 configs/mx6sabreauto_defconfig                |   67 -
 configs/mx6sabresd_defconfig                  |   75 -
 configs/nas220_defconfig                      |   42 -
 configs/omap35_logic_defconfig                |   72 -
 configs/omap35_logic_somlv_defconfig          |   78 -
 configs/omap3_beagle_defconfig                |   82 -
 configs/omap3_logic_defconfig                 |   73 -
 configs/omap3_logic_somlv_defconfig           |   78 -
 configs/omap3_overo_defconfig                 |   51 -
 configs/omap3_pandora_defconfig               |   40 -
 configs/omap3_zoom1_defconfig                 |   39 -
 configs/ot1200_defconfig                      |   46 -
 configs/ot1200_spl_defconfig                  |   55 -
 configs/pcm051_rev1_defconfig                 |   58 -
 configs/pcm051_rev3_defconfig                 |   58 -
 configs/pcm058_defconfig                      |   57 -
 configs/pengwyn_defconfig                     |   62 -
 configs/pfla02_defconfig                      |   57 -
 configs/pico-hobbit-imx7d_defconfig           |   60 -
 configs/pico-imx7d_defconfig                  |   60 -
 configs/pico-pi-imx7d_defconfig               |   60 -
 configs/riotboard_defconfig                   |   37 -
 configs/s32v234evb_defconfig                  |   17 -
 configs/sheevaplug_defconfig                  |   44 -
 configs/sksimx6_defconfig                     |   42 -
 configs/snapper9260_defconfig                 |   34 -
 configs/snapper9g20_defconfig                 |   33 -
 configs/sniper_defconfig                      |   40 -
 configs/socfpga_arria10_defconfig             |   44 -
 configs/socfpga_arria5_defconfig              |   77 -
 configs/socfpga_cyclone5_defconfig            |   78 -
 configs/socfpga_dbm_soc1_defconfig            |   70 -
 configs/socfpga_de0_nano_soc_defconfig        |   72 -
 configs/socfpga_de10_nano_defconfig           |   68 -
 configs/socfpga_de1_soc_defconfig             |   60 -
 configs/socfpga_is1_defconfig                 |   60 -
 configs/socfpga_sockit_defconfig              |   78 -
 configs/socfpga_socrates_defconfig            |   78 -
 configs/socfpga_sr1500_defconfig              |   67 -
 configs/socfpga_stratix10_defconfig           |   59 -
 configs/socfpga_vining_fpga_defconfig         |   94 -
 configs/tbs2910_defconfig                     |   58 -
 configs/theadorable_debug_defconfig           |   74 -
 configs/udoo_defconfig                        |   36 -
 configs/udoo_neo_defconfig                    |   33 -
 configs/vinco_defconfig                       |   40 -
 configs/vining_2000_defconfig                 |   43 -
 configs/wandboard_defconfig                   |   46 -
 configs/warp7_bl33_defconfig                  |   41 -
 configs/warp7_defconfig                       |   52 -
 configs/work_92105_defconfig                  |   41 -
 configs/xpress_defconfig                      |   32 -
 configs/xpress_spl_defconfig                  |   42 -
 configs/zc5202_defconfig                      |   42 -
 configs/zc5601_defconfig                      |   41 -
 doc/driver-model/MIGRATION.txt                |    8 +-
 drivers/block/Kconfig                         |    2 +-
 drivers/core/Kconfig                          |    1 +
 drivers/mmc/Kconfig                           |    2 +-
 drivers/mmc/dw_mmc.c                          |    2 +-
 drivers/mmc/mmc-uclass.c                      |    2 +-
 drivers/mmc/mmc_write.c                       |    8 +-
 drivers/usb/Kconfig                           |    1 +
 include/configs/am335x_evm.h                  |  343 ---
 include/configs/am335x_shc.h                  |  263 --
 include/configs/am43xx_evm.h                  |  292 --
 include/configs/am65x_evm.h                   |   75 -
 include/configs/ap121.h                       |   46 -
 include/configs/ap143.h                       |   50 -
 include/configs/apalis_imx6.h                 |  277 --
 include/configs/baltos.h                      |  276 --
 include/configs/bav335x.h                     |  501 ----
 include/configs/brppt1.h                      |  214 --
 include/configs/chiliboard.h                  |  180 --
 include/configs/cl-som-imx7.h                 |  182 --
 include/configs/clearfog.h                    |  157 -
 include/configs/cm_t335.h                     |  152 -
 include/configs/cm_t43.h                      |  140 -
 include/configs/colibri_imx6.h                |  251 --
 include/configs/colibri_pxa270.h              |  188 --
 include/configs/db-mv784mp-gp.h               |   99 -
 include/configs/devkit3250.h                  |  194 --
 include/configs/devkit8000.h                  |  190 --
 include/configs/dh_imx6.h                     |  178 --
 include/configs/dns325.h                      |  118 -
 include/configs/dra7xx_evm.h                  |  165 --
 include/configs/dreamplug.h                   |   83 -
 include/configs/ds109.h                       |   86 -
 include/configs/embestmx6boards.h             |  150 -
 include/configs/guruplug.h                    |   82 -
 include/configs/gw_ventana.h                  |  355 ---
 include/configs/helios4.h                     |  172 --
 include/configs/imx6_logic.h                  |  172 --
 include/configs/imx6dl-mamoj.h                |   99 -
 include/configs/kp_imx6q_tpc.h                |  134 -
 include/configs/liteboard.h                   |  155 -
 include/configs/ls1021aiot.h                  |  251 --
 include/configs/ls1021atwr.h                  |  505 ----
 include/configs/ls1043ardb.h                  |  285 --
 include/configs/ls1046ardb.h                  |  220 --
 include/configs/lsxl.h                        |  149 -
 include/configs/mccmon6.h                     |  293 --
 include/configs/mx6cuboxi.h                   |  149 -
 include/configs/mx6sabreauto.h                |   78 -
 include/configs/mx6sabresd.h                  |   67 -
 include/configs/nas220.h                      |  112 -
 include/configs/omap3_beagle.h                |  233 --
 include/configs/omap3_cairo.h                 |  231 --
 include/configs/omap3_igep00x0.h              |  135 -
 include/configs/omap3_logic.h                 |  210 --
 include/configs/omap3_overo.h                 |  192 --
 include/configs/omap3_pandora.h               |   69 -
 include/configs/omap3_zoom1.h                 |  138 -
 include/configs/ot1200.h                      |  114 -
 include/configs/pcm051.h                      |  137 -
 include/configs/pcm058.h                      |   98 -
 include/configs/pdu001.h                      |   86 -
 include/configs/pengwyn.h                     |  171 --
 include/configs/pfla02.h                      |  157 -
 include/configs/pico-imx7d.h                  |  151 -
 include/configs/s32v234evb.h                  |  190 --
 include/configs/sheevaplug.h                  |   92 -
 include/configs/sksimx6.h                     |   96 -
 include/configs/snapper9260.h                 |  123 -
 include/configs/snapper9g45.h                 |  112 -
 include/configs/sniper.h                      |  154 -
 include/configs/socfpga_arria10_socdk.h       |   50 -
 include/configs/socfpga_arria5_socdk.h        |   22 -
 include/configs/socfpga_cyclone5_socdk.h      |   22 -
 include/configs/socfpga_dbm_soc1.h            |   95 -
 include/configs/socfpga_de0_nano_soc.h        |   22 -
 include/configs/socfpga_de10_nano.h           |   22 -
 include/configs/socfpga_de1_soc.h             |   22 -
 include/configs/socfpga_is1.h                 |   34 -
 include/configs/socfpga_sockit.h              |   22 -
 include/configs/socfpga_socrates.h            |   22 -
 include/configs/socfpga_sr1500.h              |   56 -
 include/configs/socfpga_stratix10_socdk.h     |  221 --
 include/configs/socfpga_vining_fpga.h         |  180 --
 include/configs/tbs2910.h                     |  158 -
 include/configs/theadorable.h                 |  125 -
 include/configs/udoo.h                        |   95 -
 include/configs/udoo_neo.h                    |  106 -
 include/configs/vinco.h                       |  118 -
 include/configs/vining_2000.h                 |  104 -
 include/configs/wandboard.h                   |  156 -
 include/configs/warp7.h                       |  169 --
 include/configs/work_92105.h                  |  161 -
 include/configs/xpress.h                      |  135 -
 include/configs/zc5202.h                      |   30 -
 include/configs/zc5601.h                      |   28 -
 include/dwmmc.h                               |    6 +-
 tools/rmboard.py                              |  145 +
 783 files changed, 162 insertions(+), 87172 deletions(-)
 delete mode 100644 arch/arm/cpu/armv8/s32v234/Makefile
 delete mode 100644 arch/arm/cpu/armv8/s32v234/cpu.c
 delete mode 100644 arch/arm/cpu/armv8/s32v234/cpu.h
 delete mode 100644 arch/arm/cpu/armv8/s32v234/generic.c
 delete mode 100644 arch/arm/dts/imx6dl-mamoj-u-boot.dtsi
 delete mode 100644 arch/arm/dts/imx6dl-mamoj.dts
 delete mode 100644 arch/arm/include/asm/arch-am33xx/chilisom.h
 delete mode 100644 arch/arm/include/asm/arch-s32v234/clock.h
 delete mode 100644 arch/arm/include/asm/arch-s32v234/ddr.h
 delete mode 100644 arch/arm/include/asm/arch-s32v234/imx-regs.h
 delete mode 100644 arch/arm/include/asm/arch-s32v234/lpddr2.h
 delete mode 100644 arch/arm/include/asm/arch-s32v234/mc_cgm_regs.h
 delete mode 100644 arch/arm/include/asm/arch-s32v234/mc_me_regs.h
 delete mode 100644 arch/arm/include/asm/arch-s32v234/mc_rgm_regs.h
 delete mode 100644 arch/arm/include/asm/arch-s32v234/mmdc.h
 delete mode 100644 arch/arm/include/asm/arch-s32v234/siul.h
 delete mode 100644 arch/arm/mach-omap2/am33xx/chilisom.c
 delete mode 100644 board/BuR/brppt1/Kconfig
 delete mode 100644 board/BuR/brppt1/MAINTAINERS
 delete mode 100644 board/BuR/brppt1/Makefile
 delete mode 100644 board/BuR/brppt1/board.c
 delete mode 100644 board/BuR/brppt1/config.mk
 delete mode 100644 board/BuR/brppt1/mux.c
 delete mode 100644 board/Marvell/db-mv784mp-gp/MAINTAINERS
 delete mode 100644 board/Marvell/db-mv784mp-gp/Makefile
 delete mode 100644 board/Marvell/db-mv784mp-gp/db-mv784mp-gp.c
 delete mode 100644 board/Marvell/dreamplug/Kconfig
 delete mode 100644 board/Marvell/dreamplug/MAINTAINERS
 delete mode 100644 board/Marvell/dreamplug/Makefile
 delete mode 100644 board/Marvell/dreamplug/dreamplug.c
 delete mode 100644 board/Marvell/dreamplug/dreamplug.h
 delete mode 100644 board/Marvell/dreamplug/kwbimage.cfg
 delete mode 100644 board/Marvell/guruplug/Kconfig
 delete mode 100644 board/Marvell/guruplug/MAINTAINERS
 delete mode 100644 board/Marvell/guruplug/Makefile
 delete mode 100644 board/Marvell/guruplug/guruplug.c
 delete mode 100644 board/Marvell/guruplug/guruplug.h
 delete mode 100644 board/Marvell/guruplug/kwbimage.cfg
 delete mode 100644 board/Marvell/sheevaplug/Kconfig
 delete mode 100644 board/Marvell/sheevaplug/MAINTAINERS
 delete mode 100644 board/Marvell/sheevaplug/Makefile
 delete mode 100644 board/Marvell/sheevaplug/kwbimage.cfg
 delete mode 100644 board/Marvell/sheevaplug/sheevaplug.c
 delete mode 100644 board/Marvell/sheevaplug/sheevaplug.h
 delete mode 100644 board/Seagate/nas220/Kconfig
 delete mode 100644 board/Seagate/nas220/MAINTAINERS
 delete mode 100644 board/Seagate/nas220/Makefile
 delete mode 100644 board/Seagate/nas220/kwbimage.cfg
 delete mode 100644 board/Seagate/nas220/nas220.c
 delete mode 100644 board/Synology/ds109/Kconfig
 delete mode 100644 board/Synology/ds109/MAINTAINERS
 delete mode 100644 board/Synology/ds109/Makefile
 delete mode 100644 board/Synology/ds109/ds109.c
 delete mode 100644 board/Synology/ds109/ds109.h
 delete mode 100644 board/Synology/ds109/kwbimage.cfg
 delete mode 100644 board/Synology/ds109/openocd.cfg
 delete mode 100644 board/altera/arria10-socdk/Kconfig
 delete mode 100644 board/altera/arria10-socdk/MAINTAINERS
 delete mode 100644 board/altera/arria10-socdk/Makefile
 delete mode 100644 board/altera/arria10-socdk/socfpga.c
 delete mode 100644 board/altera/arria5-socdk/MAINTAINERS
 delete mode 100644 board/altera/arria5-socdk/Makefile
 delete mode 100644 board/altera/arria5-socdk/qts/iocsr_config.h
 delete mode 100644 board/altera/arria5-socdk/qts/pinmux_config.h
 delete mode 100644 board/altera/arria5-socdk/qts/pll_config.h
 delete mode 100644 board/altera/arria5-socdk/qts/sdram_config.h
 delete mode 100644 board/altera/arria5-socdk/socfpga.c
 delete mode 100644 board/altera/cyclone5-socdk/MAINTAINERS
 delete mode 100644 board/altera/cyclone5-socdk/Makefile
 delete mode 100644 board/altera/cyclone5-socdk/qts/iocsr_config.h
 delete mode 100644 board/altera/cyclone5-socdk/qts/pinmux_config.h
 delete mode 100644 board/altera/cyclone5-socdk/qts/pll_config.h
 delete mode 100644 board/altera/cyclone5-socdk/qts/sdram_config.h
 delete mode 100644 board/altera/cyclone5-socdk/socfpga.c
 delete mode 100644 board/altera/stratix10-socdk/MAINTAINERS
 delete mode 100644 board/altera/stratix10-socdk/Makefile
 delete mode 100644 board/altera/stratix10-socdk/socfpga.c
 delete mode 100644 board/bachmann/ot1200/Kconfig
 delete mode 100644 board/bachmann/ot1200/MAINTAINERS
 delete mode 100644 board/bachmann/ot1200/Makefile
 delete mode 100644 board/bachmann/ot1200/README
 delete mode 100644 board/bachmann/ot1200/mx6q_4x_mt41j128.cfg
 delete mode 100644 board/bachmann/ot1200/ot1200.c
 delete mode 100644 board/bachmann/ot1200/ot1200_spl.c
 delete mode 100644 board/birdland/bav335x/Kconfig
 delete mode 100644 board/birdland/bav335x/Makefile
 delete mode 100644 board/birdland/bav335x/README
 delete mode 100644 board/birdland/bav335x/board.c
 delete mode 100644 board/birdland/bav335x/board.h
 delete mode 100644 board/birdland/bav335x/mux.c
 delete mode 100644 board/birdland/bav335x/u-boot.lds
 delete mode 100644 board/bluewater/gurnard/Kconfig
 delete mode 100644 board/bluewater/gurnard/MAINTAINERS
 delete mode 100644 board/bluewater/gurnard/Makefile
 delete mode 100644 board/bluewater/gurnard/gurnard.c
 delete mode 100644 board/bluewater/gurnard/splash_logo.h
 delete mode 100644 board/bluewater/snapper9260/Kconfig
 delete mode 100644 board/bluewater/snapper9260/MAINTAINERS
 delete mode 100644 board/bluewater/snapper9260/Makefile
 delete mode 100644 board/bluewater/snapper9260/snapper9260.c
 delete mode 100644 board/bosch/shc/Kconfig
 delete mode 100644 board/bosch/shc/MAINTAINERS
 delete mode 100644 board/bosch/shc/Makefile
 delete mode 100644 board/bosch/shc/README
 delete mode 100644 board/bosch/shc/board.c
 delete mode 100644 board/bosch/shc/board.h
 delete mode 100644 board/bosch/shc/mux.c
 delete mode 100644 board/bticino/mamoj/Kconfig
 delete mode 100644 board/bticino/mamoj/MAINTAINERS
 delete mode 100644 board/bticino/mamoj/Makefile
 delete mode 100644 board/bticino/mamoj/README
 delete mode 100644 board/bticino/mamoj/mamoj.c
 delete mode 100644 board/bticino/mamoj/spl.c
 delete mode 100644 board/buffalo/lsxl/Kconfig
 delete mode 100644 board/buffalo/lsxl/MAINTAINERS
 delete mode 100644 board/buffalo/lsxl/Makefile
 delete mode 100644 board/buffalo/lsxl/README
 delete mode 100644 board/buffalo/lsxl/kwbimage-lschl.cfg
 delete mode 100644 board/buffalo/lsxl/kwbimage-lsxhl.cfg
 delete mode 100644 board/buffalo/lsxl/lsxl.c
 delete mode 100644 board/buffalo/lsxl/lsxl.h
 delete mode 100644 board/ccv/xpress/Kconfig
 delete mode 100644 board/ccv/xpress/MAINTAINERS
 delete mode 100644 board/ccv/xpress/Makefile
 delete mode 100644 board/ccv/xpress/imximage.cfg
 delete mode 100644 board/ccv/xpress/spl.c
 delete mode 100644 board/ccv/xpress/xpress.c
 delete mode 100644 board/compulab/cl-som-imx7/Kconfig
 delete mode 100644 board/compulab/cl-som-imx7/MAINTAINERS
 delete mode 100644 board/compulab/cl-som-imx7/Makefile
 delete mode 100644 board/compulab/cl-som-imx7/cl-som-imx7.c
 delete mode 100644 board/compulab/cl-som-imx7/common.c
 delete mode 100644 board/compulab/cl-som-imx7/common.h
 delete mode 100644 board/compulab/cl-som-imx7/mux.c
 delete mode 100644 board/compulab/cl-som-imx7/spl.c
 delete mode 100644 board/compulab/cm_t335/Kconfig
 delete mode 100644 board/compulab/cm_t335/MAINTAINERS
 delete mode 100644 board/compulab/cm_t335/Makefile
 delete mode 100644 board/compulab/cm_t335/cm_t335.c
 delete mode 100644 board/compulab/cm_t335/mux.c
 delete mode 100644 board/compulab/cm_t335/spl.c
 delete mode 100644 board/compulab/cm_t335/u-boot.lds
 delete mode 100644 board/compulab/cm_t43/Kconfig
 delete mode 100644 board/compulab/cm_t43/MAINTAINERS
 delete mode 100644 board/compulab/cm_t43/Makefile
 delete mode 100644 board/compulab/cm_t43/board.h
 delete mode 100644 board/compulab/cm_t43/cm_t43.c
 delete mode 100644 board/compulab/cm_t43/mux.c
 delete mode 100644 board/compulab/cm_t43/spl.c
 delete mode 100644 board/d-link/dns325/Kconfig
 delete mode 100644 board/d-link/dns325/MAINTAINERS
 delete mode 100644 board/d-link/dns325/Makefile
 delete mode 100644 board/d-link/dns325/dns325.c
 delete mode 100644 board/d-link/dns325/dns325.h
 delete mode 100644 board/d-link/dns325/kwbimage.cfg
 delete mode 100644 board/dhelectronics/dh_imx6/Kconfig
 delete mode 100644 board/dhelectronics/dh_imx6/MAINTAINERS
 delete mode 100644 board/dhelectronics/dh_imx6/Makefile
 delete mode 100644 board/dhelectronics/dh_imx6/dh_imx6.c
 delete mode 100644 board/dhelectronics/dh_imx6/dh_imx6_spl.c
 delete mode 100644 board/ebv/socrates/MAINTAINERS
 delete mode 100644 board/ebv/socrates/Makefile
 delete mode 100644 board/ebv/socrates/qts/iocsr_config.h
 delete mode 100644 board/ebv/socrates/qts/pinmux_config.h
 delete mode 100644 board/ebv/socrates/qts/pll_config.h
 delete mode 100644 board/ebv/socrates/qts/sdram_config.h
 delete mode 100644 board/ebv/socrates/socfpga.c
 delete mode 100644 board/eets/pdu001/Kconfig
 delete mode 100644 board/eets/pdu001/MAINTAINERS
 delete mode 100644 board/eets/pdu001/Makefile
 delete mode 100644 board/eets/pdu001/README
 delete mode 100644 board/eets/pdu001/board.c
 delete mode 100644 board/eets/pdu001/board.h
 delete mode 100644 board/eets/pdu001/mux.c
 delete mode 100644 board/el/el6x/Kconfig
 delete mode 100644 board/el/el6x/MAINTAINERS
 delete mode 100644 board/el/el6x/Makefile
 delete mode 100644 board/el/el6x/el6x.c
 delete mode 100644 board/embest/mx6boards/Kconfig
 delete mode 100644 board/embest/mx6boards/MAINTAINERS
 delete mode 100644 board/embest/mx6boards/Makefile
 delete mode 100644 board/embest/mx6boards/mx6boards.c
 delete mode 100644 board/freescale/ls1021aiot/Kconfig
 delete mode 100644 board/freescale/ls1021aiot/MAINTAINERS
 delete mode 100644 board/freescale/ls1021aiot/Makefile
 delete mode 100644 board/freescale/ls1021aiot/README
 delete mode 100644 board/freescale/ls1021aiot/dcu.c
 delete mode 100644 board/freescale/ls1021aiot/ls1021aiot.c
 delete mode 100644 board/freescale/ls1021aiot/ls102xa_pbi.cfg
 delete mode 100644 board/freescale/ls1021aiot/ls102xa_rcw_sd.cfg
 delete mode 100644 board/freescale/ls1021aiot/psci.S
 delete mode 100644 board/freescale/ls1021atwr/Kconfig
 delete mode 100644 board/freescale/ls1021atwr/MAINTAINERS
 delete mode 100644 board/freescale/ls1021atwr/Makefile
 delete mode 100644 board/freescale/ls1021atwr/README
 delete mode 100644 board/freescale/ls1021atwr/dcu.c
 delete mode 100644 board/freescale/ls1021atwr/ls1021atwr.c
 delete mode 100644 board/freescale/ls1021atwr/ls102xa_pbi.cfg
 delete mode 100644 board/freescale/ls1021atwr/ls102xa_rcw_sd_ifc.cfg
 delete mode 100644 board/freescale/ls1021atwr/ls102xa_rcw_sd_qspi.cfg
 delete mode 100644 board/freescale/ls1021atwr/psci.S
 delete mode 100644 board/freescale/ls1043ardb/Kconfig
 delete mode 100644 board/freescale/ls1043ardb/MAINTAINERS
 delete mode 100644 board/freescale/ls1043ardb/Makefile
 delete mode 100644 board/freescale/ls1043ardb/README
 delete mode 100644 board/freescale/ls1043ardb/cpld.c
 delete mode 100644 board/freescale/ls1043ardb/cpld.h
 delete mode 100644 board/freescale/ls1043ardb/ddr.c
 delete mode 100644 board/freescale/ls1043ardb/ddr.h
 delete mode 100644 board/freescale/ls1043ardb/eth.c
 delete mode 100644 board/freescale/ls1043ardb/ls1043ardb.c
 delete mode 100644 board/freescale/ls1043ardb/ls1043ardb_pbi.cfg
 delete mode 100644 board/freescale/ls1043ardb/ls1043ardb_rcw_nand.cfg
 delete mode 100644 board/freescale/ls1043ardb/ls1043ardb_rcw_sd.cfg
 delete mode 100644 board/freescale/ls1046ardb/Kconfig
 delete mode 100644 board/freescale/ls1046ardb/MAINTAINERS
 delete mode 100644 board/freescale/ls1046ardb/Makefile
 delete mode 100644 board/freescale/ls1046ardb/README
 delete mode 100644 board/freescale/ls1046ardb/cpld.c
 delete mode 100644 board/freescale/ls1046ardb/cpld.h
 delete mode 100644 board/freescale/ls1046ardb/ddr.c
 delete mode 100644 board/freescale/ls1046ardb/ddr.h
 delete mode 100644 board/freescale/ls1046ardb/eth.c
 delete mode 100644 board/freescale/ls1046ardb/ls1046ardb.c
 delete mode 100644 board/freescale/ls1046ardb/ls1046ardb_pbi.cfg
 delete mode 100644 board/freescale/ls1046ardb/ls1046ardb_qspi_pbi.cfg
 delete mode 100644 board/freescale/ls1046ardb/ls1046ardb_rcw_emmc.cfg
 delete mode 100644 board/freescale/ls1046ardb/ls1046ardb_rcw_qspi.cfg
 delete mode 100644 board/freescale/ls1046ardb/ls1046ardb_rcw_sd.cfg
 delete mode 100644 board/freescale/mx6sabreauto/Kconfig
 delete mode 100644 board/freescale/mx6sabreauto/MAINTAINERS
 delete mode 100644 board/freescale/mx6sabreauto/Makefile
 delete mode 100644 board/freescale/mx6sabreauto/README
 delete mode 100644 board/freescale/mx6sabreauto/mx6sabreauto.c
 delete mode 100644 board/freescale/mx6sabresd/Kconfig
 delete mode 100644 board/freescale/mx6sabresd/MAINTAINERS
 delete mode 100644 board/freescale/mx6sabresd/Makefile
 delete mode 100644 board/freescale/mx6sabresd/README
 delete mode 100644 board/freescale/mx6sabresd/mx6sabresd.c
 delete mode 100644 board/freescale/s32v234evb/Kconfig
 delete mode 100644 board/freescale/s32v234evb/MAINTAINERS
 delete mode 100644 board/freescale/s32v234evb/Makefile
 delete mode 100644 board/freescale/s32v234evb/clock.c
 delete mode 100644 board/freescale/s32v234evb/lpddr2.c
 delete mode 100644 board/freescale/s32v234evb/s32v234evb.c
 delete mode 100644 board/freescale/s32v234evb/s32v234evb.cfg
 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 board/grinn/chiliboard/Kconfig
 delete mode 100644 board/grinn/chiliboard/MAINTAINERS
 delete mode 100644 board/grinn/chiliboard/Makefile
 delete mode 100644 board/grinn/chiliboard/README
 delete mode 100644 board/grinn/chiliboard/board.c
 delete mode 100644 board/grinn/liteboard/Kconfig
 delete mode 100644 board/grinn/liteboard/MAINTAINERS
 delete mode 100644 board/grinn/liteboard/Makefile
 delete mode 100644 board/grinn/liteboard/README
 delete mode 100644 board/grinn/liteboard/board.c
 delete mode 100644 board/imgtec/xilfpga/Kconfig
 delete mode 100644 board/imgtec/xilfpga/MAINTAINERS
 delete mode 100644 board/imgtec/xilfpga/Makefile
 delete mode 100644 board/imgtec/xilfpga/README
 delete mode 100644 board/imgtec/xilfpga/xilfpga.c
 delete mode 100644 board/is1/MAINTAINERS
 delete mode 100644 board/is1/Makefile
 delete mode 100644 board/is1/qts/iocsr_config.h
 delete mode 100644 board/is1/qts/pinmux_config.h
 delete mode 100644 board/is1/qts/pll_config.h
 delete mode 100644 board/is1/qts/sdram_config.h
 delete mode 100644 board/is1/socfpga.c
 delete mode 100644 board/isee/igep00x0/Kconfig
 delete mode 100644 board/isee/igep00x0/MAINTAINERS
 delete mode 100644 board/isee/igep00x0/Makefile
 delete mode 100644 board/isee/igep00x0/common.c
 delete mode 100644 board/isee/igep00x0/igep00x0.c
 delete mode 100644 board/isee/igep00x0/igep00x0.h
 delete mode 100644 board/isee/igep00x0/spl.c
 delete mode 100644 board/k+p/kp_imx6q_tpc/Kconfig
 delete mode 100644 board/k+p/kp_imx6q_tpc/MAINTAINERS
 delete mode 100644 board/k+p/kp_imx6q_tpc/Makefile
 delete mode 100644 board/k+p/kp_imx6q_tpc/kp_imx6q_tpc.c
 delete mode 100644 board/k+p/kp_imx6q_tpc/kp_imx6q_tpc_spl.c
 delete mode 100644 board/kobol/helios4/MAINTAINERS
 delete mode 100644 board/kobol/helios4/Makefile
 delete mode 100644 board/kobol/helios4/README
 delete mode 100644 board/kobol/helios4/helios4.c
 delete mode 100644 board/l+g/vinco/Kconfig
 delete mode 100644 board/l+g/vinco/MAINTAINERS
 delete mode 100644 board/l+g/vinco/Makefile
 delete mode 100644 board/l+g/vinco/vinco.c
 delete mode 100644 board/lg/sniper/Kconfig
 delete mode 100644 board/lg/sniper/MAINTAINERS
 delete mode 100644 board/lg/sniper/Makefile
 delete mode 100644 board/lg/sniper/sniper.c
 delete mode 100644 board/lg/sniper/sniper.h
 delete mode 100644 board/liebherr/mccmon6/Kconfig
 delete mode 100644 board/liebherr/mccmon6/MAINTAINERS
 delete mode 100644 board/liebherr/mccmon6/Makefile
 delete mode 100644 board/liebherr/mccmon6/mccmon6.c
 delete mode 100644 board/liebherr/mccmon6/mon6_imximage_nor.cfg
 delete mode 100644 board/liebherr/mccmon6/mon6_imximage_sd.cfg
 delete mode 100644 board/liebherr/mccmon6/spl.c
 delete mode 100644 board/logicpd/imx6/Kconfig
 delete mode 100644 board/logicpd/imx6/MAINTAINERS
 delete mode 100644 board/logicpd/imx6/Makefile
 delete mode 100644 board/logicpd/imx6/README
 delete mode 100644 board/logicpd/imx6/imx6logic.c
 delete mode 100644 board/logicpd/omap3som/Kconfig
 delete mode 100644 board/logicpd/omap3som/MAINTAINERS
 delete mode 100644 board/logicpd/omap3som/Makefile
 delete mode 100644 board/logicpd/omap3som/README
 delete mode 100644 board/logicpd/omap3som/omap3logic.c
 delete mode 100644 board/logicpd/omap3som/omap3logic.h
 delete mode 100644 board/logicpd/zoom1/Kconfig
 delete mode 100644 board/logicpd/zoom1/MAINTAINERS
 delete mode 100644 board/logicpd/zoom1/Makefile
 delete mode 100644 board/logicpd/zoom1/config.mk
 delete mode 100644 board/logicpd/zoom1/zoom1.c
 delete mode 100644 board/logicpd/zoom1/zoom1.h
 delete mode 100644 board/overo/Kconfig
 delete mode 100644 board/overo/MAINTAINERS
 delete mode 100644 board/overo/Makefile
 delete mode 100644 board/overo/common.c
 delete mode 100644 board/overo/overo.c
 delete mode 100644 board/overo/overo.h
 delete mode 100644 board/overo/spl.c
 delete mode 100644 board/pandora/Kconfig
 delete mode 100644 board/pandora/MAINTAINERS
 delete mode 100644 board/pandora/Makefile
 delete mode 100644 board/pandora/pandora.c
 delete mode 100644 board/pandora/pandora.h
 delete mode 100644 board/phytec/pcm051/Kconfig
 delete mode 100644 board/phytec/pcm051/MAINTAINERS
 delete mode 100644 board/phytec/pcm051/Makefile
 delete mode 100644 board/phytec/pcm051/board.c
 delete mode 100644 board/phytec/pcm051/board.h
 delete mode 100644 board/phytec/pcm051/mux.c
 delete mode 100644 board/phytec/pcm058/Kconfig
 delete mode 100644 board/phytec/pcm058/MAINTAINERS
 delete mode 100644 board/phytec/pcm058/Makefile
 delete mode 100644 board/phytec/pcm058/README
 delete mode 100644 board/phytec/pcm058/pcm058.c
 delete mode 100644 board/phytec/pfla02/Kconfig
 delete mode 100644 board/phytec/pfla02/MAINTAINERS
 delete mode 100644 board/phytec/pfla02/Makefile
 delete mode 100644 board/phytec/pfla02/README
 delete mode 100644 board/phytec/pfla02/pfla02.c
 delete mode 100644 board/qca/ap121/Kconfig
 delete mode 100644 board/qca/ap121/MAINTAINERS
 delete mode 100644 board/qca/ap121/Makefile
 delete mode 100644 board/qca/ap121/ap121.c
 delete mode 100644 board/qca/ap143/Kconfig
 delete mode 100644 board/qca/ap143/MAINTAINERS
 delete mode 100644 board/qca/ap143/Makefile
 delete mode 100644 board/qca/ap143/ap143.c
 delete mode 100644 board/quipos/cairo/Kconfig
 delete mode 100644 board/quipos/cairo/MAINTAINERS
 delete mode 100644 board/quipos/cairo/Makefile
 delete mode 100644 board/quipos/cairo/cairo.c
 delete mode 100644 board/quipos/cairo/cairo.h
 delete mode 100644 board/samtec/vining_2000/Kconfig
 delete mode 100644 board/samtec/vining_2000/MAINTAINERS
 delete mode 100644 board/samtec/vining_2000/Makefile
 delete mode 100644 board/samtec/vining_2000/imximage.cfg
 delete mode 100644 board/samtec/vining_2000/vining_2000.c
 delete mode 100644 board/silica/pengwyn/Kconfig
 delete mode 100644 board/silica/pengwyn/MAINTAINERS
 delete mode 100644 board/silica/pengwyn/Makefile
 delete mode 100644 board/silica/pengwyn/board.c
 delete mode 100644 board/silica/pengwyn/board.h
 delete mode 100644 board/silica/pengwyn/mux.c
 delete mode 100644 board/sks-kinkel/sksimx6/Kconfig
 delete mode 100644 board/sks-kinkel/sksimx6/MAINTAINERS
 delete mode 100644 board/sks-kinkel/sksimx6/Makefile
 delete mode 100644 board/sks-kinkel/sksimx6/sksimx6.c
 delete mode 100644 board/solidrun/clearfog/MAINTAINERS
 delete mode 100644 board/solidrun/clearfog/Makefile
 delete mode 100644 board/solidrun/clearfog/README
 delete mode 100644 board/solidrun/clearfog/clearfog.c
 delete mode 100644 board/solidrun/mx6cuboxi/Kconfig
 delete mode 100644 board/solidrun/mx6cuboxi/MAINTAINERS
 delete mode 100644 board/solidrun/mx6cuboxi/Makefile
 delete mode 100644 board/solidrun/mx6cuboxi/README
 delete mode 100644 board/solidrun/mx6cuboxi/mx6cuboxi.c
 delete mode 100644 board/sr1500/MAINTAINERS
 delete mode 100644 board/sr1500/Makefile
 delete mode 100644 board/sr1500/qts/iocsr_config.h
 delete mode 100644 board/sr1500/qts/pinmux_config.h
 delete mode 100644 board/sr1500/qts/pll_config.h
 delete mode 100644 board/sr1500/qts/sdram_config.h
 delete mode 100644 board/sr1500/socfpga.c
 delete mode 100644 board/tbs/tbs2910/Kconfig
 delete mode 100644 board/tbs/tbs2910/MAINTAINERS
 delete mode 100644 board/tbs/tbs2910/Makefile
 delete mode 100644 board/tbs/tbs2910/tbs2910.c
 delete mode 100644 board/tbs/tbs2910/tbs2910.cfg
 delete mode 100644 board/technexion/pico-imx7d/Kconfig
 delete mode 100644 board/technexion/pico-imx7d/MAINTAINERS
 delete mode 100644 board/technexion/pico-imx7d/Makefile
 delete mode 100644 board/technexion/pico-imx7d/README
 delete mode 100644 board/technexion/pico-imx7d/pico-imx7d.c
 delete mode 100644 board/technexion/pico-imx7d/spl.c
 delete mode 100644 board/theadorable/MAINTAINERS
 delete mode 100644 board/theadorable/Makefile
 delete mode 100644 board/theadorable/fpga.c
 delete mode 100644 board/theadorable/theadorable.c
 delete mode 100644 board/theadorable/theadorable.h
 delete mode 100644 board/ti/am335x/Kconfig
 delete mode 100644 board/ti/am335x/MAINTAINERS
 delete mode 100644 board/ti/am335x/Makefile
 delete mode 100644 board/ti/am335x/README
 delete mode 100644 board/ti/am335x/board.c
 delete mode 100644 board/ti/am335x/board.h
 delete mode 100644 board/ti/am335x/mux.c
 delete mode 100644 board/ti/am335x/u-boot.lds
 delete mode 100644 board/ti/am43xx/Kconfig
 delete mode 100644 board/ti/am43xx/MAINTAINERS
 delete mode 100644 board/ti/am43xx/Makefile
 delete mode 100644 board/ti/am43xx/board.c
 delete mode 100644 board/ti/am43xx/board.h
 delete mode 100644 board/ti/am43xx/mux.c
 delete mode 100644 board/ti/am65x/Kconfig
 delete mode 100644 board/ti/am65x/MAINTAINERS
 delete mode 100644 board/ti/am65x/Makefile
 delete mode 100644 board/ti/am65x/README
 delete mode 100644 board/ti/am65x/evm.c
 delete mode 100644 board/ti/beagle/Kconfig
 delete mode 100644 board/ti/beagle/MAINTAINERS
 delete mode 100644 board/ti/beagle/Makefile
 delete mode 100644 board/ti/beagle/beagle.c
 delete mode 100644 board/ti/beagle/beagle.h
 delete mode 100644 board/ti/beagle/led.c
 delete mode 100644 board/ti/dra7xx/Kconfig
 delete mode 100644 board/ti/dra7xx/MAINTAINERS
 delete mode 100644 board/ti/dra7xx/Makefile
 delete mode 100644 board/ti/dra7xx/README
 delete mode 100644 board/ti/dra7xx/evm.c
 delete mode 100644 board/ti/dra7xx/mux_data.h
 delete mode 100644 board/timll/devkit3250/Kconfig
 delete mode 100644 board/timll/devkit3250/MAINTAINERS
 delete mode 100644 board/timll/devkit3250/Makefile
 delete mode 100644 board/timll/devkit3250/devkit3250.c
 delete mode 100644 board/timll/devkit3250/devkit3250_spl.c
 delete mode 100644 board/timll/devkit8000/Kconfig
 delete mode 100644 board/timll/devkit8000/MAINTAINERS
 delete mode 100644 board/timll/devkit8000/Makefile
 delete mode 100644 board/timll/devkit8000/README
 delete mode 100644 board/timll/devkit8000/devkit8000.c
 delete mode 100644 board/timll/devkit8000/devkit8000.h
 delete mode 100644 board/toradex/apalis_imx6/1066mhz_4x128mx16.cfg
 delete mode 100644 board/toradex/apalis_imx6/1066mhz_4x256mx16.cfg
 delete mode 100644 board/toradex/apalis_imx6/Kconfig
 delete mode 100644 board/toradex/apalis_imx6/MAINTAINERS
 delete mode 100644 board/toradex/apalis_imx6/Makefile
 delete mode 100644 board/toradex/apalis_imx6/apalis_imx6.c
 delete mode 100644 board/toradex/apalis_imx6/apalis_imx6q.cfg
 delete mode 100644 board/toradex/apalis_imx6/clocks.cfg
 delete mode 100644 board/toradex/apalis_imx6/ddr-setup.cfg
 delete mode 100644 board/toradex/apalis_imx6/do_fuse.c
 delete mode 100644 board/toradex/apalis_imx6/pf0100.c
 delete mode 100644 board/toradex/apalis_imx6/pf0100.h
 delete mode 100644 board/toradex/apalis_imx6/pf0100_otp.inc
 delete mode 100644 board/toradex/colibri_imx6/800mhz_2x64mx16.cfg
 delete mode 100644 board/toradex/colibri_imx6/800mhz_4x64mx16.cfg
 delete mode 100644 board/toradex/colibri_imx6/Kconfig
 delete mode 100644 board/toradex/colibri_imx6/MAINTAINERS
 delete mode 100644 board/toradex/colibri_imx6/Makefile
 delete mode 100644 board/toradex/colibri_imx6/clocks.cfg
 delete mode 100644 board/toradex/colibri_imx6/colibri_imx6.c
 delete mode 100644 board/toradex/colibri_imx6/colibri_imx6.cfg
 delete mode 100644 board/toradex/colibri_imx6/ddr-setup.cfg
 delete mode 100644 board/toradex/colibri_imx6/do_fuse.c
 delete mode 100644 board/toradex/colibri_imx6/pf0100.c
 delete mode 100644 board/toradex/colibri_imx6/pf0100.h
 delete mode 100644 board/toradex/colibri_imx6/pf0100_otp.inc
 delete mode 100644 board/toradex/colibri_pxa270/Kconfig
 delete mode 100644 board/toradex/colibri_pxa270/MAINTAINERS
 delete mode 100644 board/toradex/colibri_pxa270/Makefile
 delete mode 100644 board/toradex/colibri_pxa270/colibri_pxa270.c
 delete mode 100644 board/udoo/Kconfig
 delete mode 100644 board/udoo/MAINTAINERS
 delete mode 100644 board/udoo/Makefile
 delete mode 100644 board/udoo/README
 delete mode 100644 board/udoo/neo/Kconfig
 delete mode 100644 board/udoo/neo/MAINTAINERS
 delete mode 100644 board/udoo/neo/Makefile
 delete mode 100644 board/udoo/neo/neo.c
 delete mode 100644 board/udoo/udoo.c
 delete mode 100644 board/udoo/udoo_spl.c
 delete mode 100644 board/vscom/baltos/Kconfig
 delete mode 100644 board/vscom/baltos/MAINTAINERS
 delete mode 100644 board/vscom/baltos/Makefile
 delete mode 100644 board/vscom/baltos/README
 delete mode 100644 board/vscom/baltos/board.c
 delete mode 100644 board/vscom/baltos/board.h
 delete mode 100644 board/vscom/baltos/mux.c
 delete mode 100644 board/vscom/baltos/u-boot.lds
 delete mode 100644 board/wandboard/Kconfig
 delete mode 100644 board/wandboard/MAINTAINERS
 delete mode 100644 board/wandboard/Makefile
 delete mode 100644 board/wandboard/README
 delete mode 100644 board/wandboard/spl.c
 delete mode 100644 board/wandboard/wandboard.c
 delete mode 100644 board/warp7/Kconfig
 delete mode 100644 board/warp7/MAINTAINERS
 delete mode 100644 board/warp7/Makefile
 delete mode 100644 board/warp7/README
 delete mode 100644 board/warp7/imximage.cfg
 delete mode 100644 board/warp7/warp7.c
 delete mode 100644 board/work-microwave/work_92105/Kconfig
 delete mode 100644 board/work-microwave/work_92105/MAINTAINERS
 delete mode 100644 board/work-microwave/work_92105/Makefile
 delete mode 100644 board/work-microwave/work_92105/README
 delete mode 100644 board/work-microwave/work_92105/work_92105.c
 delete mode 100644 board/work-microwave/work_92105/work_92105_display.c
 delete mode 100644 board/work-microwave/work_92105/work_92105_display.h
 delete mode 100644 board/work-microwave/work_92105/work_92105_spl.c
 delete mode 100644 configs/am335x_baltos_defconfig
 delete mode 100644 configs/am335x_boneblack_defconfig
 delete mode 100644 configs/am335x_boneblack_vboot_defconfig
 delete mode 100644 configs/am335x_evm_defconfig
 delete mode 100644 configs/am335x_evm_nor_defconfig
 delete mode 100644 configs/am335x_evm_norboot_defconfig
 delete mode 100644 configs/am335x_evm_spiboot_defconfig
 delete mode 100644 configs/am335x_evm_usbspl_defconfig
 delete mode 100644 configs/am335x_pdu001_defconfig
 delete mode 100644 configs/am335x_shc_defconfig
 delete mode 100644 configs/am335x_shc_ict_defconfig
 delete mode 100644 configs/am335x_shc_netboot_defconfig
 delete mode 100644 configs/am335x_shc_prompt_defconfig
 delete mode 100644 configs/am335x_shc_sdboot_defconfig
 delete mode 100644 configs/am335x_shc_sdboot_prompt_defconfig
 delete mode 100644 configs/am43xx_evm_defconfig
 delete mode 100644 configs/am43xx_evm_ethboot_defconfig
 delete mode 100644 configs/am43xx_evm_qspiboot_defconfig
 delete mode 100644 configs/am43xx_evm_rtconly_defconfig
 delete mode 100644 configs/am43xx_evm_usbhost_boot_defconfig
 delete mode 100644 configs/am43xx_hs_evm_defconfig
 delete mode 100644 configs/am65x_evm_a53_defconfig
 delete mode 100644 configs/am65x_evm_r5_defconfig
 delete mode 100644 configs/ap121_defconfig
 delete mode 100644 configs/ap143_defconfig
 delete mode 100644 configs/apalis_imx6_defconfig
 delete mode 100644 configs/apalis_imx6_nospl_com_defconfig
 delete mode 100644 configs/apalis_imx6_nospl_it_defconfig
 delete mode 100644 configs/birdland_bav335a_defconfig
 delete mode 100644 configs/birdland_bav335b_defconfig
 delete mode 100644 configs/brppt1_mmc_defconfig
 delete mode 100644 configs/brppt1_nand_defconfig
 delete mode 100644 configs/brppt1_spi_defconfig
 delete mode 100644 configs/cairo_defconfig
 delete mode 100644 configs/chiliboard_defconfig
 delete mode 100644 configs/cl-som-imx7_defconfig
 delete mode 100644 configs/clearfog_defconfig
 delete mode 100644 configs/cm_t335_defconfig
 delete mode 100644 configs/cm_t43_defconfig
 delete mode 100644 configs/colibri_imx6_defconfig
 delete mode 100644 configs/colibri_imx6_nospl_defconfig
 delete mode 100644 configs/colibri_pxa270_defconfig
 delete mode 100644 configs/db-mv784mp-gp_defconfig
 delete mode 100644 configs/devkit3250_defconfig
 delete mode 100644 configs/devkit8000_defconfig
 delete mode 100644 configs/dh_imx6_defconfig
 delete mode 100644 configs/dns325_defconfig
 delete mode 100644 configs/dra7xx_evm_defconfig
 delete mode 100644 configs/dra7xx_hs_evm_defconfig
 delete mode 100644 configs/dreamplug_defconfig
 delete mode 100644 configs/ds109_defconfig
 delete mode 100644 configs/gurnard_defconfig
 delete mode 100644 configs/guruplug_defconfig
 delete mode 100644 configs/gwventana_emmc_defconfig
 delete mode 100644 configs/gwventana_gw5904_defconfig
 delete mode 100644 configs/gwventana_nand_defconfig
 delete mode 100644 configs/helios4_defconfig
 delete mode 100644 configs/igep0032_defconfig
 delete mode 100644 configs/igep00x0_defconfig
 delete mode 100644 configs/imgtec_xilfpga_defconfig
 delete mode 100644 configs/imx6dl_mamoj_defconfig
 delete mode 100644 configs/imx6q_logic_defconfig
 delete mode 100644 configs/kp_imx6q_tpc_defconfig
 delete mode 100644 configs/liteboard_defconfig
 delete mode 100644 configs/ls1021aiot_qspi_defconfig
 delete mode 100644 configs/ls1021aiot_sdcard_defconfig
 delete mode 100644 configs/ls1021atwr_nor_SECURE_BOOT_defconfig
 delete mode 100644 configs/ls1021atwr_nor_defconfig
 delete mode 100644 configs/ls1021atwr_nor_lpuart_defconfig
 delete mode 100644 configs/ls1021atwr_qspi_defconfig
 delete mode 100644 configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig
 delete mode 100644 configs/ls1021atwr_sdcard_ifc_defconfig
 delete mode 100644 configs/ls1021atwr_sdcard_qspi_defconfig
 delete mode 100644 configs/ls1043ardb_SECURE_BOOT_defconfig
 delete mode 100644 configs/ls1043ardb_defconfig
 delete mode 100644 configs/ls1043ardb_nand_SECURE_BOOT_defconfig
 delete mode 100644 configs/ls1043ardb_nand_defconfig
 delete mode 100644 configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig
 delete mode 100644 configs/ls1043ardb_sdcard_defconfig
 delete mode 100644 configs/ls1046ardb_emmc_defconfig
 delete mode 100644 configs/ls1046ardb_qspi_SECURE_BOOT_defconfig
 delete mode 100644 configs/ls1046ardb_qspi_defconfig
 delete mode 100644 configs/ls1046ardb_qspi_spl_defconfig
 delete mode 100644 configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig
 delete mode 100644 configs/ls1046ardb_sdcard_defconfig
 delete mode 100644 configs/lschlv2_defconfig
 delete mode 100644 configs/lsxhl_defconfig
 delete mode 100644 configs/marsboard_defconfig
 delete mode 100644 configs/mccmon6_nor_defconfig
 delete mode 100644 configs/mccmon6_sd_defconfig
 delete mode 100644 configs/mx6cuboxi_defconfig
 delete mode 100644 configs/mx6sabreauto_defconfig
 delete mode 100644 configs/mx6sabresd_defconfig
 delete mode 100644 configs/nas220_defconfig
 delete mode 100644 configs/omap35_logic_defconfig
 delete mode 100644 configs/omap35_logic_somlv_defconfig
 delete mode 100644 configs/omap3_beagle_defconfig
 delete mode 100644 configs/omap3_logic_defconfig
 delete mode 100644 configs/omap3_logic_somlv_defconfig
 delete mode 100644 configs/omap3_overo_defconfig
 delete mode 100644 configs/omap3_pandora_defconfig
 delete mode 100644 configs/omap3_zoom1_defconfig
 delete mode 100644 configs/ot1200_defconfig
 delete mode 100644 configs/ot1200_spl_defconfig
 delete mode 100644 configs/pcm051_rev1_defconfig
 delete mode 100644 configs/pcm051_rev3_defconfig
 delete mode 100644 configs/pcm058_defconfig
 delete mode 100644 configs/pengwyn_defconfig
 delete mode 100644 configs/pfla02_defconfig
 delete mode 100644 configs/pico-hobbit-imx7d_defconfig
 delete mode 100644 configs/pico-imx7d_defconfig
 delete mode 100644 configs/pico-pi-imx7d_defconfig
 delete mode 100644 configs/riotboard_defconfig
 delete mode 100644 configs/s32v234evb_defconfig
 delete mode 100644 configs/sheevaplug_defconfig
 delete mode 100644 configs/sksimx6_defconfig
 delete mode 100644 configs/snapper9260_defconfig
 delete mode 100644 configs/snapper9g20_defconfig
 delete mode 100644 configs/sniper_defconfig
 delete mode 100644 configs/socfpga_arria10_defconfig
 delete mode 100644 configs/socfpga_arria5_defconfig
 delete mode 100644 configs/socfpga_cyclone5_defconfig
 delete mode 100644 configs/socfpga_dbm_soc1_defconfig
 delete mode 100644 configs/socfpga_de0_nano_soc_defconfig
 delete mode 100644 configs/socfpga_de10_nano_defconfig
 delete mode 100644 configs/socfpga_de1_soc_defconfig
 delete mode 100644 configs/socfpga_is1_defconfig
 delete mode 100644 configs/socfpga_sockit_defconfig
 delete mode 100644 configs/socfpga_socrates_defconfig
 delete mode 100644 configs/socfpga_sr1500_defconfig
 delete mode 100644 configs/socfpga_stratix10_defconfig
 delete mode 100644 configs/socfpga_vining_fpga_defconfig
 delete mode 100644 configs/tbs2910_defconfig
 delete mode 100644 configs/theadorable_debug_defconfig
 delete mode 100644 configs/udoo_defconfig
 delete mode 100644 configs/udoo_neo_defconfig
 delete mode 100644 configs/vinco_defconfig
 delete mode 100644 configs/vining_2000_defconfig
 delete mode 100644 configs/wandboard_defconfig
 delete mode 100644 configs/warp7_bl33_defconfig
 delete mode 100644 configs/warp7_defconfig
 delete mode 100644 configs/work_92105_defconfig
 delete mode 100644 configs/xpress_defconfig
 delete mode 100644 configs/xpress_spl_defconfig
 delete mode 100644 configs/zc5202_defconfig
 delete mode 100644 configs/zc5601_defconfig
 delete mode 100644 include/configs/am335x_evm.h
 delete mode 100644 include/configs/am335x_shc.h
 delete mode 100644 include/configs/am43xx_evm.h
 delete mode 100644 include/configs/am65x_evm.h
 delete mode 100644 include/configs/ap121.h
 delete mode 100644 include/configs/ap143.h
 delete mode 100644 include/configs/apalis_imx6.h
 delete mode 100644 include/configs/baltos.h
 delete mode 100644 include/configs/bav335x.h
 delete mode 100644 include/configs/brppt1.h
 delete mode 100644 include/configs/chiliboard.h
 delete mode 100644 include/configs/cl-som-imx7.h
 delete mode 100644 include/configs/clearfog.h
 delete mode 100644 include/configs/cm_t335.h
 delete mode 100644 include/configs/cm_t43.h
 delete mode 100644 include/configs/colibri_imx6.h
 delete mode 100644 include/configs/colibri_pxa270.h
 delete mode 100644 include/configs/db-mv784mp-gp.h
 delete mode 100644 include/configs/devkit3250.h
 delete mode 100644 include/configs/devkit8000.h
 delete mode 100644 include/configs/dh_imx6.h
 delete mode 100644 include/configs/dns325.h
 delete mode 100644 include/configs/dra7xx_evm.h
 delete mode 100644 include/configs/dreamplug.h
 delete mode 100644 include/configs/ds109.h
 delete mode 100644 include/configs/embestmx6boards.h
 delete mode 100644 include/configs/guruplug.h
 delete mode 100644 include/configs/gw_ventana.h
 delete mode 100644 include/configs/helios4.h
 delete mode 100644 include/configs/imx6_logic.h
 delete mode 100644 include/configs/imx6dl-mamoj.h
 delete mode 100644 include/configs/kp_imx6q_tpc.h
 delete mode 100644 include/configs/liteboard.h
 delete mode 100644 include/configs/ls1021aiot.h
 delete mode 100644 include/configs/ls1021atwr.h
 delete mode 100644 include/configs/ls1043ardb.h
 delete mode 100644 include/configs/ls1046ardb.h
 delete mode 100644 include/configs/lsxl.h
 delete mode 100644 include/configs/mccmon6.h
 delete mode 100644 include/configs/mx6cuboxi.h
 delete mode 100644 include/configs/mx6sabreauto.h
 delete mode 100644 include/configs/mx6sabresd.h
 delete mode 100644 include/configs/nas220.h
 delete mode 100644 include/configs/omap3_beagle.h
 delete mode 100644 include/configs/omap3_cairo.h
 delete mode 100644 include/configs/omap3_igep00x0.h
 delete mode 100644 include/configs/omap3_logic.h
 delete mode 100644 include/configs/omap3_overo.h
 delete mode 100644 include/configs/omap3_pandora.h
 delete mode 100644 include/configs/omap3_zoom1.h
 delete mode 100644 include/configs/ot1200.h
 delete mode 100644 include/configs/pcm051.h
 delete mode 100644 include/configs/pcm058.h
 delete mode 100644 include/configs/pdu001.h
 delete mode 100644 include/configs/pengwyn.h
 delete mode 100644 include/configs/pfla02.h
 delete mode 100644 include/configs/pico-imx7d.h
 delete mode 100644 include/configs/s32v234evb.h
 delete mode 100644 include/configs/sheevaplug.h
 delete mode 100644 include/configs/sksimx6.h
 delete mode 100644 include/configs/snapper9260.h
 delete mode 100644 include/configs/snapper9g45.h
 delete mode 100644 include/configs/sniper.h
 delete mode 100644 include/configs/socfpga_arria10_socdk.h
 delete mode 100644 include/configs/socfpga_arria5_socdk.h
 delete mode 100644 include/configs/socfpga_cyclone5_socdk.h
 delete mode 100644 include/configs/socfpga_dbm_soc1.h
 delete mode 100644 include/configs/socfpga_de0_nano_soc.h
 delete mode 100644 include/configs/socfpga_de10_nano.h
 delete mode 100644 include/configs/socfpga_de1_soc.h
 delete mode 100644 include/configs/socfpga_is1.h
 delete mode 100644 include/configs/socfpga_sockit.h
 delete mode 100644 include/configs/socfpga_socrates.h
 delete mode 100644 include/configs/socfpga_sr1500.h
 delete mode 100644 include/configs/socfpga_stratix10_socdk.h
 delete mode 100644 include/configs/socfpga_vining_fpga.h
 delete mode 100644 include/configs/tbs2910.h
 delete mode 100644 include/configs/theadorable.h
 delete mode 100644 include/configs/udoo.h
 delete mode 100644 include/configs/udoo_neo.h
 delete mode 100644 include/configs/vinco.h
 delete mode 100644 include/configs/vining_2000.h
 delete mode 100644 include/configs/wandboard.h
 delete mode 100644 include/configs/warp7.h
 delete mode 100644 include/configs/work_92105.h
 delete mode 100644 include/configs/xpress.h
 delete mode 100644 include/configs/zc5202.h
 delete mode 100644 include/configs/zc5601.h
 create mode 100755 tools/rmboard.py

Quoted 6 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.

Fabio, Stefano,

it seems (almost?) all i.mx6 boards should be removed within two weeks. But would it not make more sense to convert the reference boards first (mx6sabresd
in my case for tbs2910), and let hobbyist maintainers like me take this as example for
their own modifications?

Simon, Tom,

is this really the usual u-boot working style to remove about hundred boards within
two weeks without prior warning? As hobbyist board maintainer I try to follow
new developments, and more than once I fixed up regressions introduced by others
in general code.
But I cannot follow all development details without any heads-up. And even the
NXP folks seem to be surprised about this.

All problems with this transition seem to be located around usbstorage and sata.
This is for sure not really very board specific. Is there any migration guide, or
examples how other SoC architectures did this conversion?

Quoted 9 lines · Soeren Moch

Quoted 6 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.

Quoted 8 lines

Fabio, Stefano,

it seems (almost?) all i.mx6 boards should be removed within two weeks. But would it not make more sense to convert the reference boards first (mx6sabresd
in my case for tbs2910), and let hobbyist maintainers like me take this as example for
their own modifications?

So, I replied to the main thread earlier but no, we're not going to drop everything in 2 weeks, especially since there's a lot of false positives in this series.

Quoted 13 lines

Simon, Tom,

is this really the usual u-boot working style to remove about hundred boards within
two weeks without prior warning? As hobbyist board maintainer I try to follow
new developments, and more than once I fixed up regressions introduced by others
in general code.
But I cannot follow all development details without any heads-up. And even the
NXP folks seem to be surprised about this.

Quoted 5 lines

All problems with this transition seem to be located around usbstorage and sata.
This is for sure not really very board specific. Is there any migration guide, or
examples how other SoC architectures did this conversion?

I'll admit this hasn't been our best notification. But, the deadline was discussed about a year ago (and then no, I didn't get a build-time warning in). Then around v2018.05 I said it wasn't going to be a removal type problem yet as we had a lot of boards to fixup still, and repeated that at v2018.07. That did lead to a lot of things getting addressed. But yes, we still have some large areas that after a few years still have not been converted, and that puts me in a hard spot too.

Quoted 42 lines · Tom Rini

Quoted 9 lines · Soeren Moch

Quoted 6 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.

Quoted 8 lines

Fabio, Stefano,

it seems (almost?) all i.mx6 boards should be removed within two weeks. But would it not make more sense to convert the reference boards first (mx6sabresd
in my case for tbs2910), and let hobbyist maintainers like me take this as example for
their own modifications?

So, I replied to the main thread earlier but no, we're not going to drop everything in 2 weeks, especially since there's a lot of false positives in this series.

Quoted 13 lines

Simon, Tom,

is this really the usual u-boot working style to remove about hundred boards within
two weeks without prior warning? As hobbyist board maintainer I try to follow
new developments, and more than once I fixed up regressions introduced by others
in general code.
But I cannot follow all development details without any heads-up. And even the
NXP folks seem to be surprised about this.

Quoted 5 lines

All problems with this transition seem to be located around usbstorage and sata.
This is for sure not really very board specific. Is there any migration guide, or
examples how other SoC architectures did this conversion?

Quoted 8 lines

I'll admit this hasn't been our best notification. But, the deadline was discussed about a year ago (and then no, I didn't get a build-time warning in). Then around v2018.05 I said it wasn't going to be a removal type problem yet as we had a lot of boards to fixup still, and repeated that at v2018.07. That did lead to a lot of things getting addressed. But yes, we still have some large areas that after a few years still have not been converted, and that puts me in a hard spot too.

Build time warning for a year would be good ?

Maybe we need some generic Makefile macro to set those up.

Quoted 52 lines · Marek Vasut

Quoted 50 lines · Tom Rini

Quoted 9 lines · Soeren Moch

Quoted 6 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.

Quoted 8 lines

Fabio, Stefano,

it seems (almost?) all i.mx6 boards should be removed within two weeks. But would it not make more sense to convert the reference boards first (mx6sabresd
in my case for tbs2910), and let hobbyist maintainers like me take this as example for
their own modifications?

So, I replied to the main thread earlier but no, we're not going to drop everything in 2 weeks, especially since there's a lot of false positives in this series.

Quoted 13 lines

Simon, Tom,

is this really the usual u-boot working style to remove about hundred boards within
two weeks without prior warning? As hobbyist board maintainer I try to follow
new developments, and more than once I fixed up regressions introduced by others
in general code.
But I cannot follow all development details without any heads-up. And even the
NXP folks seem to be surprised about this.

Quoted 5 lines

All problems with this transition seem to be located around usbstorage and sata.
This is for sure not really very board specific. Is there any migration guide, or
examples how other SoC architectures did this conversion?

I'll admit this hasn't been our best notification. But, the deadline was discussed about a year ago (and then no, I didn't get a build-time warning in). Then around v2018.05 I said it wasn't going to be a removal type problem yet as we had a lot of boards to fixup still, and repeated that at v2018.07. That did lead to a lot of things getting addressed. But yes, we still have some large areas that after a few years still have not been converted, and that puts me in a hard spot too.

Quoted 1 line

Build time warning for a year would be good ?

A year for this? No. New deadlines? That's not too far off from what we've done historically, so yes.

Quoted 1 line

Maybe we need some generic Makefile macro to set those up.

It would be nice, yes. I think the problem here is (or, was) the complex set of options that didn't work.

Quoted 53 lines · Tom Rini

Quoted 52 lines · Marek Vasut

Quoted 50 lines · Tom Rini

Quoted 9 lines · Soeren Moch

Quoted 6 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.

Quoted 8 lines

Fabio, Stefano,

it seems (almost?) all i.mx6 boards should be removed within two weeks. But would it not make more sense to convert the reference boards first (mx6sabresd
in my case for tbs2910), and let hobbyist maintainers like me take this as example for
their own modifications?

So, I replied to the main thread earlier but no, we're not going to drop everything in 2 weeks, especially since there's a lot of false positives in this series.

Quoted 13 lines

Simon, Tom,

is this really the usual u-boot working style to remove about hundred boards within
two weeks without prior warning? As hobbyist board maintainer I try to follow
new developments, and more than once I fixed up regressions introduced by others
in general code.
But I cannot follow all development details without any heads-up. And even the
NXP folks seem to be surprised about this.

Quoted 5 lines

All problems with this transition seem to be located around usbstorage and sata.
This is for sure not really very board specific. Is there any migration guide, or
examples how other SoC architectures did this conversion?

I'll admit this hasn't been our best notification. But, the deadline was discussed about a year ago (and then no, I didn't get a build-time warning in). Then around v2018.05 I said it wasn't going to be a removal type problem yet as we had a lot of boards to fixup still, and repeated that at v2018.07. That did lead to a lot of things getting addressed. But yes, we still have some large areas that after a few years still have not been converted, and that puts me in a hard spot too.

Quoted 4 lines

Quoted 1 line

Build time warning for a year would be good ?

A year for this? No. New deadlines? That's not too far off from what we've done historically, so yes.

Give people some sort of breathing space to get the conversion done. Stressing people out by arbitrary deadlines will lead nowhere.

Quoted 4 lines

Quoted 1 line

Maybe we need some generic Makefile macro to set those up.

It would be nice, yes. I think the problem here is (or, was) the complex set of options that didn't work.

The problem was many people didn't know about the conversion deadline or simply forgot. And reminding them with a 100-patch series removing half of the boards is like splashing icy water bucket in their sleeping faces.

Quoted 54 lines · Marek Vasut

Quoted 53 lines · Tom Rini

Quoted 52 lines · Marek Vasut

Quoted 50 lines · Tom Rini

Quoted 9 lines · Soeren Moch

Quoted 6 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.

Quoted 8 lines

Fabio, Stefano,

it seems (almost?) all i.mx6 boards should be removed within two weeks. But would it not make more sense to convert the reference boards first (mx6sabresd
in my case for tbs2910), and let hobbyist maintainers like me take this as example for
their own modifications?

So, I replied to the main thread earlier but no, we're not going to drop everything in 2 weeks, especially since there's a lot of false positives in this series.

Quoted 13 lines

Simon, Tom,

is this really the usual u-boot working style to remove about hundred boards within
two weeks without prior warning? As hobbyist board maintainer I try to follow
new developments, and more than once I fixed up regressions introduced by others
in general code.
But I cannot follow all development details without any heads-up. And even the
NXP folks seem to be surprised about this.

Quoted 5 lines

All problems with this transition seem to be located around usbstorage and sata.
This is for sure not really very board specific. Is there any migration guide, or
examples how other SoC architectures did this conversion?

I'll admit this hasn't been our best notification. But, the deadline was discussed about a year ago (and then no, I didn't get a build-time warning in). Then around v2018.05 I said it wasn't going to be a removal type problem yet as we had a lot of boards to fixup still, and repeated that at v2018.07. That did lead to a lot of things getting addressed. But yes, we still have some large areas that after a few years still have not been converted, and that puts me in a hard spot too.

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

Build time warning for a year would be good ?

A year for this? No. New deadlines? That's not too far off from what we've done historically, so yes.

Give people some sort of breathing space to get the conversion done. Stressing people out by arbitrary deadlines will lead nowhere.

Sure, agreed. I didn't say we're going to drop all these boards, nor are we going to drop SATA and USB Storage (if those are still all that's left to convert) for this release. But given that we proposed a deadline in August 2017, made email-but-not-build noise about it between May and July/August of this year, no, I also don't think setting a new deadline of November 2019 is the right call either.

So, really, lets see what the fails to build boards are with BLK being on when we have block devices. Then assess what a good deadline is.

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

Maybe we need some generic Makefile macro to set those up.

It would be nice, yes. I think the problem here is (or, was) the complex set of options that didn't work.

The problem was many people didn't know about the conversion deadline or simply forgot. And reminding them with a 100-patch series removing half of the boards is like splashing icy water bucket in their sleeping faces.

Alright. But we've already tried less shocking approaches to conversion, but in public (over the summer when Simon listed most of these boards in a series but I _think_ his script failed to CC the universe and didn't follow up with a repost that did email everyone) and perhaps private too (I honestly don't recall if I did, or just intended to, ask you about the USB side of this on IRC).

Quoted 54 lines · Marek Vasut

Quoted 53 lines · Tom Rini

Quoted 52 lines · Marek Vasut

Quoted 50 lines · Tom Rini

Quoted 9 lines · Soeren Moch

Quoted 6 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.

Quoted 8 lines

Fabio, Stefano,

it seems (almost?) all i.mx6 boards should be removed within two weeks. But would it not make more sense to convert the reference boards first (mx6sabresd
in my case for tbs2910), and let hobbyist maintainers like me take this as example for
their own modifications?

So, I replied to the main thread earlier but no, we're not going to drop everything in 2 weeks, especially since there's a lot of false positives in this series.

Quoted 13 lines

Simon, Tom,

is this really the usual u-boot working style to remove about hundred boards within
two weeks without prior warning? As hobbyist board maintainer I try to follow
new developments, and more than once I fixed up regressions introduced by others
in general code.
But I cannot follow all development details without any heads-up. And even the
NXP folks seem to be surprised about this.

Quoted 5 lines

All problems with this transition seem to be located around usbstorage and sata.
This is for sure not really very board specific. Is there any migration guide, or
examples how other SoC architectures did this conversion?

I'll admit this hasn't been our best notification. But, the deadline was discussed about a year ago (and then no, I didn't get a build-time warning in). Then around v2018.05 I said it wasn't going to be a removal type problem yet as we had a lot of boards to fixup still, and repeated that at v2018.07. That did lead to a lot of things getting addressed. But yes, we still have some large areas that after a few years still have not been converted, and that puts me in a hard spot too.

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

Build time warning for a year would be good ?

A year for this? No. New deadlines? That's not too far off from what we've done historically, so yes.

Give people some sort of breathing space to get the conversion done. Stressing people out by arbitrary deadlines will lead nowhere.

Sure, agreed. I didn't say we're going to drop all these boards, nor are we going to drop SATA and USB Storage (if those are still all that's left to convert) for this release. But given that we proposed a deadline in August 2017, made email-but-not-build noise about it between May and July/August of this year, no, I also don't think setting a new deadline of November 2019 is the right call either.

So, really, lets see what the fails to build boards are with BLK being on when we have block devices. Then assess what a good deadline is.

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

Maybe we need some generic Makefile macro to set those up.

It would be nice, yes. I think the problem here is (or, was) the complex set of options that didn't work.

The problem was many people didn't know about the conversion deadline or simply forgot. And reminding them with a 100-patch series removing half of the boards is like splashing icy water bucket in their sleeping faces.

Alright. But we've already tried less shocking approaches to conversion, but in public (over the summer when Simon listed most of these boards in a series but I _think_ his script failed to CC the universe and didn't follow up with a repost that did email everyone) and perhaps private too (I honestly don't recall if I did, or just intended to, ask you about the USB side of this on IRC).

Quoted 82 lines · Tom Rini

Quoted 54 lines · Marek Vasut

Quoted 53 lines · Tom Rini

Quoted 52 lines · Marek Vasut

Quoted 50 lines · Tom Rini

Quoted 9 lines · Soeren Moch

Quoted 6 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.

Quoted 8 lines

Fabio, Stefano,

it seems (almost?) all i.mx6 boards should be removed within two weeks. But would it not make more sense to convert the reference boards first (mx6sabresd
in my case for tbs2910), and let hobbyist maintainers like me take this as example for
their own modifications?

So, I replied to the main thread earlier but no, we're not going to drop everything in 2 weeks, especially since there's a lot of false positives in this series.

Quoted 13 lines

Simon, Tom,

is this really the usual u-boot working style to remove about hundred boards within
two weeks without prior warning? As hobbyist board maintainer I try to follow
new developments, and more than once I fixed up regressions introduced by others
in general code.
But I cannot follow all development details without any heads-up. And even the
NXP folks seem to be surprised about this.

Quoted 5 lines

All problems with this transition seem to be located around usbstorage and sata.
This is for sure not really very board specific. Is there any migration guide, or
examples how other SoC architectures did this conversion?

I'll admit this hasn't been our best notification. But, the deadline was discussed about a year ago (and then no, I didn't get a build-time warning in). Then around v2018.05 I said it wasn't going to be a removal type problem yet as we had a lot of boards to fixup still, and repeated that at v2018.07. That did lead to a lot of things getting addressed. But yes, we still have some large areas that after a few years still have not been converted, and that puts me in a hard spot too.

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

Build time warning for a year would be good ?

A year for this? No. New deadlines? That's not too far off from what we've done historically, so yes.

Give people some sort of breathing space to get the conversion done. Stressing people out by arbitrary deadlines will lead nowhere.

Sure, agreed. I didn't say we're going to drop all these boards, nor are we going to drop SATA and USB Storage (if those are still all that's left to convert) for this release. But given that we proposed a deadline in August 2017, made email-but-not-build noise about it between May and July/August of this year, no, I also don't think setting a new deadline of November 2019 is the right call either.

So, really, lets see what the fails to build boards are with BLK being on when we have block devices. Then assess what a good deadline is.

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

Maybe we need some generic Makefile macro to set those up.

It would be nice, yes. I think the problem here is (or, was) the complex set of options that didn't work.

The problem was many people didn't know about the conversion deadline or simply forgot. And reminding them with a 100-patch series removing half of the boards is like splashing icy water bucket in their sleeping faces.

Quoted 6 lines

Alright. But we've already tried less shocking approaches to conversion, but in public (over the summer when Simon listed most of these boards in a series but I _think_ his script failed to CC the universe and didn't follow up with a repost that did email everyone) and perhaps private too (I honestly don't recall if I did, or just intended to, ask you about the USB side of this on IRC).

And, for the record, the USB side I had in mind here was converted, and I just forgot, my fault. In fact, as I go through some hack-and-slash to see what needs a real conversion (either board updated, or drivers updated) at least some part of this is needing to adjust dependencies to force things on with BLK. For example, if we have MMC we must have DM_MMC and BLK, and if we have USB we must have DM_USB and BLK.

Hi Tom,

Quoted 91 lines · Tom Rini

Quoted 88 lines · Tom Rini

Quoted 54 lines · Marek Vasut

Quoted 53 lines · Tom Rini

Quoted 52 lines · Marek Vasut

Quoted 50 lines · Tom Rini

Quoted 9 lines · Soeren Moch

Quoted 6 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.

Quoted 8 lines

Fabio, Stefano,

it seems (almost?) all i.mx6 boards should be removed within two weeks. But would it not make more sense to convert the reference boards first (mx6sabresd
in my case for tbs2910), and let hobbyist maintainers like me take this as example for
their own modifications?

So, I replied to the main thread earlier but no, we're not going to drop everything in 2 weeks, especially since there's a lot of false positives in this series.

Quoted 13 lines

Simon, Tom,

is this really the usual u-boot working style to remove about hundred boards within
two weeks without prior warning? As hobbyist board maintainer I try to follow
new developments, and more than once I fixed up regressions introduced by others
in general code.
But I cannot follow all development details without any heads-up. And even the
NXP folks seem to be surprised about this.

Quoted 5 lines

All problems with this transition seem to be located around usbstorage and sata.
This is for sure not really very board specific. Is there any migration guide, or
examples how other SoC architectures did this conversion?

I'll admit this hasn't been our best notification. But, the deadline was discussed about a year ago (and then no, I didn't get a build-time warning in). Then around v2018.05 I said it wasn't going to be a removal type problem yet as we had a lot of boards to fixup still, and repeated that at v2018.07. That did lead to a lot of things getting addressed. But yes, we still have some large areas that after a few years still have not been converted, and that puts me in a hard spot too.

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

Build time warning for a year would be good ?

A year for this? No. New deadlines? That's not too far off from what we've done historically, so yes.

Give people some sort of breathing space to get the conversion done. Stressing people out by arbitrary deadlines will lead nowhere.

Sure, agreed. I didn't say we're going to drop all these boards, nor are we going to drop SATA and USB Storage (if those are still all that's left to convert) for this release. But given that we proposed a deadline in August 2017, made email-but-not-build noise about it between May and July/August of this year, no, I also don't think setting a new deadline of November 2019 is the right call either.

So, really, lets see what the fails to build boards are with BLK being on when we have block devices. Then assess what a good deadline is.

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

Maybe we need some generic Makefile macro to set those up.

It would be nice, yes. I think the problem here is (or, was) the complex set of options that didn't work.

The problem was many people didn't know about the conversion deadline or simply forgot. And reminding them with a 100-patch series removing half of the boards is like splashing icy water bucket in their sleeping faces.

Alright. But we've already tried less shocking approaches to conversion, but in public (over the summer when Simon listed most of these boards in a series but I _think_ his script failed to CC the universe and didn't follow up with a repost that did email everyone) and perhaps private too (I honestly don't recall if I did, or just intended to, ask you about the USB side of this on IRC).

Quoted 6 lines

And, for the record, the USB side I had in mind here was converted, and I just forgot, my fault. In fact, as I go through some hack-and-slash to see what needs a real conversion (either board updated, or drivers updated) at least some part of this is needing to adjust dependencies to force things on with BLK. For example, if we have MMC we must have DM_MMC and BLK, and if we have USB we must have DM_USB and BLK.

Well, once we are through the migration we can remove BLK.

Yes all the block devices are related, and we should use DM for all of them to make this work.

I am not sure if there is a better way to do this with Kconfig.

Thanks for helping with all of this. I have found it quite tricky to plot a path forward which is why I am been putting it off for several months.

Quoted 101 lines · Simon Glass

Hi Tom,

Quoted 97 lines · Tom Rini

Quoted 82 lines · Tom Rini

Quoted 54 lines · Marek Vasut

Quoted 53 lines · Tom Rini

Quoted 52 lines · Marek Vasut

Quoted 50 lines · Tom Rini

Quoted 9 lines · Soeren Moch

Quoted 6 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.

Quoted 8 lines

Fabio, Stefano,

it seems (almost?) all i.mx6 boards should be removed within two weeks. But would it not make more sense to convert the reference boards first (mx6sabresd
in my case for tbs2910), and let hobbyist maintainers like me take this as example for
their own modifications?

So, I replied to the main thread earlier but no, we're not going to drop everything in 2 weeks, especially since there's a lot of false positives in this series.

Quoted 13 lines

Simon, Tom,

is this really the usual u-boot working style to remove about hundred boards within
two weeks without prior warning? As hobbyist board maintainer I try to follow
new developments, and more than once I fixed up regressions introduced by others
in general code.
But I cannot follow all development details without any heads-up. And even the
NXP folks seem to be surprised about this.

Quoted 5 lines

All problems with this transition seem to be located around usbstorage and sata.
This is for sure not really very board specific. Is there any migration guide, or
examples how other SoC architectures did this conversion?

I'll admit this hasn't been our best notification. But, the deadline was discussed about a year ago (and then no, I didn't get a build-time warning in). Then around v2018.05 I said it wasn't going to be a removal type problem yet as we had a lot of boards to fixup still, and repeated that at v2018.07. That did lead to a lot of things getting addressed. But yes, we still have some large areas that after a few years still have not been converted, and that puts me in a hard spot too.

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

Build time warning for a year would be good ?

A year for this? No. New deadlines? That's not too far off from what we've done historically, so yes.

Give people some sort of breathing space to get the conversion done. Stressing people out by arbitrary deadlines will lead nowhere.

Sure, agreed. I didn't say we're going to drop all these boards, nor are we going to drop SATA and USB Storage (if those are still all that's left to convert) for this release. But given that we proposed a deadline in August 2017, made email-but-not-build noise about it between May and July/August of this year, no, I also don't think setting a new deadline of November 2019 is the right call either.

So, really, lets see what the fails to build boards are with BLK being on when we have block devices. Then assess what a good deadline is.

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

Maybe we need some generic Makefile macro to set those up.

It would be nice, yes. I think the problem here is (or, was) the complex set of options that didn't work.

The problem was many people didn't know about the conversion deadline or simply forgot. And reminding them with a 100-patch series removing half of the boards is like splashing icy water bucket in their sleeping faces.

Quoted 6 lines

Alright. But we've already tried less shocking approaches to conversion, but in public (over the summer when Simon listed most of these boards in a series but I _think_ his script failed to CC the universe and didn't follow up with a repost that did email everyone) and perhaps private too (I honestly don't recall if I did, or just intended to, ask you about the USB side of this on IRC).

And, for the record, the USB side I had in mind here was converted, and I just forgot, my fault. In fact, as I go through some hack-and-slash to see what needs a real conversion (either board updated, or drivers updated) at least some part of this is needing to adjust dependencies to force things on with BLK. For example, if we have MMC we must have DM_MMC and BLK, and if we have USB we must have DM_USB and BLK.

Quoted 1 line

Well, once we are through the migration we can remove BLK.

I don't think BLK the symbol goes away, really. We don't want more objects built unconditionally and we will continue to have block device-less builds.

Quoted 9 lines

Yes all the block devices are related, and we should use DM for all of them to make this work.

I am not sure if there is a better way to do this with Kconfig.

Thanks for helping with all of this. I have found it quite tricky to plot a path forward which is why I am been putting it off for several months.

Thanks for starting it off. I think part of the big problem we'll have here is that unfortunately we can't key off of the BLK migration itself as it's short-hand for having started using OF_CONTROL. What I'm currently working through is being able to have all block drivers using BLK and everything is still building / linking as unconverted drivers now depend on BROKEN. This is showing we have a few widely used but unconverted drivers over in Freescale/NXP land.

Hi Tom,

Quoted 103 lines · Tom Rini

Quoted 101 lines · Simon Glass

Hi Tom,

Quoted 97 lines · Tom Rini

Quoted 82 lines · Tom Rini

Quoted 54 lines · Marek Vasut

Quoted 53 lines · Tom Rini

Quoted 52 lines · Marek Vasut

Quoted 50 lines · Tom Rini

Quoted 9 lines · Soeren Moch

Quoted 6 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.

Quoted 8 lines

Fabio, Stefano,

it seems (almost?) all i.mx6 boards should be removed within two weeks. But would it not make more sense to convert the reference boards first (mx6sabresd
in my case for tbs2910), and let hobbyist maintainers like me take this as example for
their own modifications?

So, I replied to the main thread earlier but no, we're not going to drop everything in 2 weeks, especially since there's a lot of false positives in this series.

Quoted 13 lines

Simon, Tom,

is this really the usual u-boot working style to remove about hundred boards within
two weeks without prior warning? As hobbyist board maintainer I try to follow
new developments, and more than once I fixed up regressions introduced by others
in general code.
But I cannot follow all development details without any heads-up. And even the
NXP folks seem to be surprised about this.

Quoted 5 lines

All problems with this transition seem to be located around usbstorage and sata.
This is for sure not really very board specific. Is there any migration guide, or
examples how other SoC architectures did this conversion?

I'll admit this hasn't been our best notification. But, the deadline was discussed about a year ago (and then no, I didn't get a build-time warning in). Then around v2018.05 I said it wasn't going to be a removal type problem yet as we had a lot of boards to fixup still, and repeated that at v2018.07. That did lead to a lot of things getting addressed. But yes, we still have some large areas that after a few years still have not been converted, and that puts me in a hard spot too.

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

Build time warning for a year would be good ?

A year for this? No. New deadlines? That's not too far off from what we've done historically, so yes.

Give people some sort of breathing space to get the conversion done. Stressing people out by arbitrary deadlines will lead nowhere.

Sure, agreed. I didn't say we're going to drop all these boards, nor are we going to drop SATA and USB Storage (if those are still all that's left to convert) for this release. But given that we proposed a deadline in August 2017, made email-but-not-build noise about it between May and July/August of this year, no, I also don't think setting a new deadline of November 2019 is the right call either.

So, really, lets see what the fails to build boards are with BLK being on when we have block devices. Then assess what a good deadline is.

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

Maybe we need some generic Makefile macro to set those up.

It would be nice, yes. I think the problem here is (or, was) the complex set of options that didn't work.

The problem was many people didn't know about the conversion deadline or simply forgot. And reminding them with a 100-patch series removing half of the boards is like splashing icy water bucket in their sleeping faces.

Quoted 6 lines

Alright. But we've already tried less shocking approaches to conversion, but in public (over the summer when Simon listed most of these boards in a series but I _think_ his script failed to CC the universe and didn't follow up with a repost that did email everyone) and perhaps private too (I honestly don't recall if I did, or just intended to, ask you about the USB side of this on IRC).

And, for the record, the USB side I had in mind here was converted, and I just forgot, my fault. In fact, as I go through some hack-and-slash to see what needs a real conversion (either board updated, or drivers updated) at least some part of this is needing to adjust dependencies to force things on with BLK. For example, if we have MMC we must have DM_MMC and BLK, and if we have USB we must have DM_USB and BLK.

Quoted 5 lines

Quoted 1 line

Well, once we are through the migration we can remove BLK.

I don't think BLK the symbol goes away, really. We don't want more objects built unconditionally and we will continue to have block device-less builds.

Yes that's right - but it becomes an optional feature rather than an indication of completed migration.

Quoted 10 lines

Quoted 9 lines

Yes all the block devices are related, and we should use DM for all of them to make this work.

I am not sure if there is a better way to do this with Kconfig.

Thanks for helping with all of this. I have found it quite tricky to plot a path forward which is why I am been putting it off for several months.

Quoted 7 lines

Thanks for starting it off. I think part of the big problem we'll have here is that unfortunately we can't key off of the BLK migration itself as it's short-hand for having started using OF_CONTROL. What I'm currently working through is being able to have all block drivers using BLK and everything is still building / linking as unconverted drivers now depend on BROKEN. This is showing we have a few widely used but unconverted drivers over in Freescale/NXP land.

That's a good idea. Does it work OK with DM_MMC and DM_USB? Is this a way we can keep unconverted boards around for a while without holding up migration? They won't work properly but will build?

Quoted 133 lines · Simon Glass

Hi Tom,

Quoted 103 lines · Tom Rini

Quoted 101 lines · Simon Glass

Hi Tom,

Quoted 97 lines · Tom Rini

Quoted 82 lines · Tom Rini

Quoted 54 lines · Marek Vasut

Quoted 53 lines · Tom Rini

Quoted 52 lines · Marek Vasut

Quoted 50 lines · Tom Rini

Quoted 9 lines · Soeren Moch

Quoted 6 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.

Quoted 8 lines

Fabio, Stefano,

it seems (almost?) all i.mx6 boards should be removed within two weeks. But would it not make more sense to convert the reference boards first (mx6sabresd
in my case for tbs2910), and let hobbyist maintainers like me take this as example for
their own modifications?

So, I replied to the main thread earlier but no, we're not going to drop everything in 2 weeks, especially since there's a lot of false positives in this series.

Quoted 13 lines

Simon, Tom,

is this really the usual u-boot working style to remove about hundred boards within
two weeks without prior warning? As hobbyist board maintainer I try to follow
new developments, and more than once I fixed up regressions introduced by others
in general code.
But I cannot follow all development details without any heads-up. And even the
NXP folks seem to be surprised about this.

Quoted 5 lines

All problems with this transition seem to be located around usbstorage and sata.
This is for sure not really very board specific. Is there any migration guide, or
examples how other SoC architectures did this conversion?

I'll admit this hasn't been our best notification. But, the deadline was discussed about a year ago (and then no, I didn't get a build-time warning in). Then around v2018.05 I said it wasn't going to be a removal type problem yet as we had a lot of boards to fixup still, and repeated that at v2018.07. That did lead to a lot of things getting addressed. But yes, we still have some large areas that after a few years still have not been converted, and that puts me in a hard spot too.

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

Build time warning for a year would be good ?

A year for this? No. New deadlines? That's not too far off from what we've done historically, so yes.

Give people some sort of breathing space to get the conversion done. Stressing people out by arbitrary deadlines will lead nowhere.

Sure, agreed. I didn't say we're going to drop all these boards, nor are we going to drop SATA and USB Storage (if those are still all that's left to convert) for this release. But given that we proposed a deadline in August 2017, made email-but-not-build noise about it between May and July/August of this year, no, I also don't think setting a new deadline of November 2019 is the right call either.

So, really, lets see what the fails to build boards are with BLK being on when we have block devices. Then assess what a good deadline is.

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

Maybe we need some generic Makefile macro to set those up.

It would be nice, yes. I think the problem here is (or, was) the complex set of options that didn't work.

The problem was many people didn't know about the conversion deadline or simply forgot. And reminding them with a 100-patch series removing half of the boards is like splashing icy water bucket in their sleeping faces.

Quoted 6 lines

Alright. But we've already tried less shocking approaches to conversion, but in public (over the summer when Simon listed most of these boards in a series but I _think_ his script failed to CC the universe and didn't follow up with a repost that did email everyone) and perhaps private too (I honestly don't recall if I did, or just intended to, ask you about the USB side of this on IRC).

And, for the record, the USB side I had in mind here was converted, and I just forgot, my fault. In fact, as I go through some hack-and-slash to see what needs a real conversion (either board updated, or drivers updated) at least some part of this is needing to adjust dependencies to force things on with BLK. For example, if we have MMC we must have DM_MMC and BLK, and if we have USB we must have DM_USB and BLK.

Quoted 5 lines

Quoted 1 line

Well, once we are through the migration we can remove BLK.

I don't think BLK the symbol goes away, really. We don't want more objects built unconditionally and we will continue to have block device-less builds.

Yes that's right - but it becomes an optional feature rather than an indication of completed migration.

Quoted 10 lines

Quoted 9 lines

Yes all the block devices are related, and we should use DM for all of them to make this work.

I am not sure if there is a better way to do this with Kconfig.

Thanks for helping with all of this. I have found it quite tricky to plot a path forward which is why I am been putting it off for several months.

Quoted 7 lines

Thanks for starting it off. I think part of the big problem we'll have here is that unfortunately we can't key off of the BLK migration itself as it's short-hand for having started using OF_CONTROL. What I'm currently working through is being able to have all block drivers using BLK and everything is still building / linking as unconverted drivers now depend on BROKEN. This is showing we have a few widely used but unconverted drivers over in Freescale/NXP land.

Quoted 3 lines

That's a good idea. Does it work OK with DM_MMC and DM_USB? Is this a way we can keep unconverted boards around for a while without holding up migration? They won't work properly but will build?

I have some worthwhile changes in my WIP branch I haven't yet posted, but, I think the problem is that we can't make BLK conversion the next hard deadline. In order to make BLK (and DM) hard requirements, all of MMC needs to be switched over (along with all of USB block related and SATA, but MMC is the big one). That in turn shows a _lot_ of different problems. We have:
- Drivers used by platforms which are using DM for other things but aren't converted
- Platforms that could be switched to using DM but haven't yet, and sometimes their storage controller is converted and sometimes it isn't.
- What feels like almost all of PowerPC/MPC85xx at least.

So I think we should maybe try is:
- Pressing on the various folks that use MPC85xx/iMX to get some of their drivers converted. This I think will allow us to fairly soon mark SCSI/SATA as fully converted.
- I want to try re-working some of the Kconfig logic today so that we have for example, DM_MMC pulling in BLK.
- Check in further with our iMX maintainers to see what they feel is misssing before being able to fully convert.
- Check in with our Marvell maintainers to see what's missing before they can fully convert.
- Check in with our USB maintainers to see what's missing before we can fully convert them, aside from the PowerPC issue.

Hi Tom,

Quoted 152 lines · Tom Rini

Quoted 133 lines · Simon Glass

Hi Tom,

Quoted 103 lines · Tom Rini

Quoted 101 lines · Simon Glass

Hi Tom,

Quoted 97 lines · Tom Rini

Quoted 82 lines · Tom Rini

Quoted 54 lines · Marek Vasut

Quoted 53 lines · Tom Rini

Quoted 52 lines · Marek Vasut

Quoted 50 lines · Tom Rini

Quoted 9 lines · Soeren Moch

Quoted 6 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.

Quoted 8 lines

Fabio, Stefano,

it seems (almost?) all i.mx6 boards should be removed within two weeks. But would it not make more sense to convert the reference boards first (mx6sabresd
in my case for tbs2910), and let hobbyist maintainers like me take this as example for
their own modifications?

So, I replied to the main thread earlier but no, we're not going to drop everything in 2 weeks, especially since there's a lot of false positives in this series.

Quoted 13 lines

Simon, Tom,

is this really the usual u-boot working style to remove about hundred boards within
two weeks without prior warning? As hobbyist board maintainer I try to follow
new developments, and more than once I fixed up regressions introduced by others
in general code.
But I cannot follow all development details without any heads-up. And even the
NXP folks seem to be surprised about this.

Quoted 5 lines

All problems with this transition seem to be located around usbstorage and sata.
This is for sure not really very board specific. Is there any migration guide, or
examples how other SoC architectures did this conversion?

I'll admit this hasn't been our best notification. But, the deadline was discussed about a year ago (and then no, I didn't get a build-time warning in). Then around v2018.05 I said it wasn't going to be a removal type problem yet as we had a lot of boards to fixup still, and repeated that at v2018.07. That did lead to a lot of things getting addressed. But yes, we still have some large areas that after a few years still have not been converted, and that puts me in a hard spot too.

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

Build time warning for a year would be good ?

A year for this? No. New deadlines? That's not too far off from what we've done historically, so yes.

Give people some sort of breathing space to get the conversion done. Stressing people out by arbitrary deadlines will lead nowhere.

Sure, agreed. I didn't say we're going to drop all these boards, nor are we going to drop SATA and USB Storage (if those are still all that's left to convert) for this release. But given that we proposed a deadline in August 2017, made email-but-not-build noise about it between May and July/August of this year, no, I also don't think setting a new deadline of November 2019 is the right call either.

So, really, lets see what the fails to build boards are with BLK being on when we have block devices. Then assess what a good deadline is.

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

Maybe we need some generic Makefile macro to set those up.

It would be nice, yes. I think the problem here is (or, was) the complex set of options that didn't work.

The problem was many people didn't know about the conversion deadline or simply forgot. And reminding them with a 100-patch series removing half of the boards is like splashing icy water bucket in their sleeping faces.

Quoted 6 lines

Alright. But we've already tried less shocking approaches to conversion, but in public (over the summer when Simon listed most of these boards in a series but I _think_ his script failed to CC the universe and didn't follow up with a repost that did email everyone) and perhaps private too (I honestly don't recall if I did, or just intended to, ask you about the USB side of this on IRC).

And, for the record, the USB side I had in mind here was converted, and I just forgot, my fault. In fact, as I go through some hack-and-slash to see what needs a real conversion (either board updated, or drivers updated) at least some part of this is needing to adjust dependencies to force things on with BLK. For example, if we have MMC we must have DM_MMC and BLK, and if we have USB we must have DM_USB and BLK.

Quoted 5 lines

Quoted 1 line

Well, once we are through the migration we can remove BLK.

I don't think BLK the symbol goes away, really. We don't want more objects built unconditionally and we will continue to have block device-less builds.

Yes that's right - but it becomes an optional feature rather than an indication of completed migration.

Quoted 10 lines

Quoted 9 lines

Yes all the block devices are related, and we should use DM for all of them to make this work.

I am not sure if there is a better way to do this with Kconfig.

Thanks for helping with all of this. I have found it quite tricky to plot a path forward which is why I am been putting it off for several months.

Quoted 7 lines

Thanks for starting it off. I think part of the big problem we'll have here is that unfortunately we can't key off of the BLK migration itself as it's short-hand for having started using OF_CONTROL. What I'm currently working through is being able to have all block drivers using BLK and everything is still building / linking as unconverted drivers now depend on BROKEN. This is showing we have a few widely used but unconverted drivers over in Freescale/NXP land.

Quoted 3 lines

That's a good idea. Does it work OK with DM_MMC and DM_USB? Is this a way we can keep unconverted boards around for a while without holding up migration? They won't work properly but will build?

I have some worthwhile changes in my WIP branch I haven't yet posted, but, I think the problem is that we can't make BLK conversion the next hard deadline. In order to make BLK (and DM) hard requirements, all of MMC needs to be switched over (along with all of USB block related and SATA, but MMC is the big one). That in turn shows a _lot_ of different problems. We have:
- Drivers used by platforms which are using DM for other things but aren't converted
- Platforms that could be switched to using DM but haven't yet, and sometimes their storage controller is converted and sometimes it isn't.
- What feels like almost all of PowerPC/MPC85xx at least.

Quoted 12 lines

So I think we should maybe try is:
- Pressing on the various folks that use MPC85xx/iMX to get some of their drivers converted. This I think will allow us to fairly soon mark SCSI/SATA as fully converted.
- I want to try re-working some of the Kconfig logic today so that we have for example, DM_MMC pulling in BLK.
- Check in further with our iMX maintainers to see what they feel is misssing before being able to fully convert.
- Check in with our Marvell maintainers to see what's missing before they can fully convert.
- Check in with our USB maintainers to see what's missing before we can fully convert them, aside from the PowerPC issue.

So you are suggesting a more 'bottom-up' approach where driver owners do work before board owners?

Anyway this seems reasonable to me. For the case where boards could be converted (drivers exist) but are not, perhaps a removal patch makes sense.

Quoted 168 lines · Simon Glass

Hi Tom,

Quoted 152 lines · Tom Rini

Quoted 133 lines · Simon Glass

Hi Tom,

Quoted 103 lines · Tom Rini

Quoted 101 lines · Simon Glass

Hi Tom,

Quoted 97 lines · Tom Rini

Quoted 82 lines · Tom Rini

Quoted 54 lines · Marek Vasut

Quoted 53 lines · Tom Rini

Quoted 52 lines · Marek Vasut

Quoted 50 lines · Tom Rini

Quoted 17 lines · Soeren Moch

On 19.11.18 16:52, 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.
Fabio, Stefano,

it seems (almost?) all i.mx6 boards should be removed within two weeks.
But would it not make more sense to convert the reference boards first
(mx6sabresd
in my case for tbs2910), and let hobbyist maintainers like me take this
as example for
their own modifications?

So, I replied to the main thread earlier but no, we're not going to drop everything in 2 weeks, especially since there's a lot of false positives in this series.

Quoted 18 lines

Simon, Tom,

is this really the usual u-boot working style to remove about hundred
boards within
two weeks without prior warning? As hobbyist board maintainer I try to
follow
new developments, and more than once I fixed up regressions introduced
by others
in general code.
But I cannot follow all development details without any heads-up. And
even the
NXP folks seem to be surprised about this.

All problems with this transition seem to be located around usbstorage
and sata.
This is for sure not really very board specific. Is there any migration
guide, or
examples how other SoC architectures did this conversion?

I'll admit this hasn't been our best notification. But, the deadline was discussed about a year ago (and then no, I didn't get a build-time warning in). Then around v2018.05 I said it wasn't going to be a removal type problem yet as we had a lot of boards to fixup still, and repeated that at v2018.07. That did lead to a lot of things getting addressed. But yes, we still have some large areas that after a few years still have not been converted, and that puts me in a hard spot too.

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

Build time warning for a year would be good ?

A year for this? No. New deadlines? That's not too far off from what we've done historically, so yes.

Give people some sort of breathing space to get the conversion done. Stressing people out by arbitrary deadlines will lead nowhere.

Sure, agreed. I didn't say we're going to drop all these boards, nor are we going to drop SATA and USB Storage (if those are still all that's left to convert) for this release. But given that we proposed a deadline in August 2017, made email-but-not-build noise about it between May and July/August of this year, no, I also don't think setting a new deadline of November 2019 is the right call either.

So, really, lets see what the fails to build boards are with BLK being on when we have block devices. Then assess what a good deadline is.

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

Maybe we need some generic Makefile macro to set those up.

It would be nice, yes. I think the problem here is (or, was) the complex set of options that didn't work.

The problem was many people didn't know about the conversion deadline or simply forgot. And reminding them with a 100-patch series removing half of the boards is like splashing icy water bucket in their sleeping faces.

Quoted 6 lines

Alright. But we've already tried less shocking approaches to conversion, but in public (over the summer when Simon listed most of these boards in a series but I _think_ his script failed to CC the universe and didn't follow up with a repost that did email everyone) and perhaps private too (I honestly don't recall if I did, or just intended to, ask you about the USB side of this on IRC).

And, for the record, the USB side I had in mind here was converted, and I just forgot, my fault. In fact, as I go through some hack-and-slash to see what needs a real conversion (either board updated, or drivers updated) at least some part of this is needing to adjust dependencies to force things on with BLK. For example, if we have MMC we must have DM_MMC and BLK, and if we have USB we must have DM_USB and BLK.

Quoted 5 lines

Quoted 1 line

Well, once we are through the migration we can remove BLK.

I don't think BLK the symbol goes away, really. We don't want more objects built unconditionally and we will continue to have block device-less builds.

Yes that's right - but it becomes an optional feature rather than an indication of completed migration.

Quoted 10 lines

Quoted 9 lines

Yes all the block devices are related, and we should use DM for all of them to make this work.

I am not sure if there is a better way to do this with Kconfig.

Thanks for helping with all of this. I have found it quite tricky to plot a path forward which is why I am been putting it off for several months.

Quoted 7 lines

Thanks for starting it off. I think part of the big problem we'll have here is that unfortunately we can't key off of the BLK migration itself as it's short-hand for having started using OF_CONTROL. What I'm currently working through is being able to have all block drivers using BLK and everything is still building / linking as unconverted drivers now depend on BROKEN. This is showing we have a few widely used but unconverted drivers over in Freescale/NXP land.

Quoted 3 lines

That's a good idea. Does it work OK with DM_MMC and DM_USB? Is this a way we can keep unconverted boards around for a while without holding up migration? They won't work properly but will build?

I have some worthwhile changes in my WIP branch I haven't yet posted, but, I think the problem is that we can't make BLK conversion the next hard deadline. In order to make BLK (and DM) hard requirements, all of MMC needs to be switched over (along with all of USB block related and SATA, but MMC is the big one). That in turn shows a _lot_ of different problems. We have:
- Drivers used by platforms which are using DM for other things but aren't converted
- Platforms that could be switched to using DM but haven't yet, and sometimes their storage controller is converted and sometimes it isn't.
- What feels like almost all of PowerPC/MPC85xx at least.

Quoted 12 lines

So I think we should maybe try is:
- Pressing on the various folks that use MPC85xx/iMX to get some of their drivers converted. This I think will allow us to fairly soon mark SCSI/SATA as fully converted.
- I want to try re-working some of the Kconfig logic today so that we have for example, DM_MMC pulling in BLK.
- Check in further with our iMX maintainers to see what they feel is misssing before being able to fully convert.
- Check in with our Marvell maintainers to see what's missing before they can fully convert.
- Check in with our USB maintainers to see what's missing before we can fully convert them, aside from the PowerPC issue.

Quoted 2 lines

So you are suggesting a more 'bottom-up' approach where driver owners do work before board owners?

In essence, yes. We _do_ have some board issues (for example, omap3_beagle doesn't Just Work when switched to DM_MMC, and my first reaction is that it probably needs to be updated to have all the various DTB files for the various "beagleboard" variants and updated to load the right one in SPL) but we have a lot more widely used drivers that need converting. I tried to cover this in my RFC series today but as I also listed above, unless we're going to remove huge swaths of boards, we can't pull the trigger yet. But I do hope this will have set off enough alarm bells to get this technical debt paid down a bit.

Quoted 4 lines

Anyway this seems reasonable to me. For the case where boards could be converted (drivers exist) but are not, perhaps a removal patch makes sense.

In time, yes, after we've had the build-time warnings showing up for a bit. And some boards can be easily converted, I'm pretty sure (ie all of sunxi).

Fabio, Stefano,

it seems (almost?) all i.mx6 boards should be removed within two weeks. But would it not make more sense to convert the reference boards first (mx6sabresd
in my case for tbs2910), and let hobbyist maintainers like me take this as example for
their own modifications?

Hi Soeren,

Quoted 8 lines · Soeren Moch

Fabio, Stefano,

it seems (almost?) all i.mx6 boards should be removed within two weeks. But would it not make more sense to convert the reference boards first (mx6sabresd
in my case for tbs2910), and let hobbyist maintainers like me take this as example for
their own modifications?

There are some imx boards that use DM:

git grep CONFIG_OF_CONTROL configs/ | grep mx

You can use them as a reference for converting tbs2910.

Also disable USB_STORAGE as it is not ready for the switch. Tested on a Beagleboard xM rev. B.

Signed-off-by Guillaume GARDET <[email protected]>

Cc Tom Rini <[email protected]>

Cc Simon Glass <[email protected]>

Quoted 8 lines

Also disable USB_STORAGE as it is not ready for the switch. Tested on a Beagleboard xM rev. B.

Signed-off-by Guillaume GARDET <[email protected]>

Cc Tom Rini <[email protected]>

Cc Simon Glass <[email protected]>

In the case of USB_STORAGE we need to turn on DM_USB and then it works.

Quoted 5 lines · Tom Rini

Quoted 3 lines · Guillaume GARDET

Also disable USB_STORAGE as it is not ready for the switch. Tested on a Beagleboard xM rev. B.

Quoted 5 lines

Quoted 4 lines

Signed-off-by Guillaume GARDET <[email protected]>

Cc Tom Rini <[email protected]>

Cc Simon Glass <[email protected]>

In the case of USB_STORAGE we need to turn on DM_USB and then it works.

If DM_USB is enabled, no USB controller are detected, so we loose Ethernet. Did I miss an additional option to enable?

Guillaume

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
https://lists.denx.de/listinfo/u-boot

Quoted 8 lines · Guillaume Gardet

Quoted 5 lines · Tom Rini

Quoted 3 lines · Guillaume GARDET

Also disable USB_STORAGE as it is not ready for the switch. Tested on a Beagleboard xM rev. B.

Quoted 8 lines

Quoted 5 lines

Quoted 4 lines

Signed-off-by Guillaume GARDET <[email protected]>

Cc Tom Rini <[email protected]>

Cc Simon Glass <[email protected]>

In the case of USB_STORAGE we need to turn on DM_USB and then it works.

If DM_USB is enabled, no USB controller are detected, so we loose Ethernet. Did I miss an additional option to enable?

AFASK, the MUSB driver didn't yet support gadget mode when used with DM_USB... at least until recently. I noticed that part of the MUSB driver was updated, but the omap2430 glue hasn't been updated yet. I am not 100% sure, but I think the Beagle xM is a DM3730 which uses the omap2430 glue. I doubt TI will update the omap2430 glue, so I started some stuff. I've got on patch that seems to show the usb gadget controller in the DM tree, but my board hangs when I try to use a gadget.

It's not ready for the mailing list yet, but I can push this stuff to my github later today if someone wants to look at it and/or test/improve it.

adam

Quoted 8 lines

Guillaume

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
https://lists.denx.de/listinfo/u-boot

Quoted 8 lines · Guillaume Gardet

Quoted 5 lines · Tom Rini

Quoted 3 lines · Guillaume GARDET

Also disable USB_STORAGE as it is not ready for the switch. Tested on a Beagleboard xM rev. B.

Quoted 8 lines

Quoted 5 lines

Quoted 4 lines

Signed-off-by Guillaume GARDET <[email protected]>

Cc Tom Rini <[email protected]>

Cc Simon Glass <[email protected]>

In the case of USB_STORAGE we need to turn on DM_USB and then it works.

If DM_USB is enabled, no USB controller are detected, so we loose Ethernet. Did I miss an additional option to enable?

AFASK, the MUSB driver didn't yet support gadget mode when used with DM_USB... at least until recently. I noticed that part of the MUSB driver was updated, but the omap2430 glue hasn't been updated yet. I am not 100% sure, but I think the Beagle xM is a DM3730 which uses the omap2430 glue. I doubt TI will update the omap2430 glue, so I started some stuff. I've got on patch that seems to show the usb gadget controller in the DM tree, but my board hangs when I try to use a gadget.

It's not ready for the mailing list yet, but I can push this stuff to my github later today if someone wants to look at it and/or test/improve it.

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.