| Message ID | 20181119155413.158098-1-sjg@chromium.org |
|---|---|
| Headers | show |
| Series | dm: Move towards completing CONFIG_BLK migration | expand |
Hello Simon, On Mon, Nov 19, 2018 at 1:52 PM Simon Glass <sjg@chromium.org> wrote: > All boards should now be migrated to use CONFIG_BLK. This series removes > those with build problems using this option. I understand and support the goal here but it seems a little abrupt to send it on a short notice. It'd be nice if the build were triggering a build warning to notify about the deadline. I wasn't aware of the deadline.
On Mon, Nov 19, 2018 at 10:54 AM Simon Glass <sjg@chromium.org> wrote: > > All boards should now be migrated to use CONFIG_BLK. This series removes > those with build problems using this option. > > If maintainers want to keep these boards in they should send a patch in > the next week or two. Otherwise the board will be removed in the next > release, and will need to be added and re-reviewed later. > > The goal is to have all boards use driver model. But so far, we do allow > CONFIG_DM to not be defined. > > PLEASE NOTE: This is not an easy process. It is possible that your board > does work, or works with only minor changes. Please try to understand that > the removal of a board is not done because people don't like your board. > In fact the board might have been the first one I used when trying out > U-Boot! It's just that we expect maintainers to keep up with the migration > to driver model which has been running now for 4 years. It just isn't > possible for a few people to migrate and test hundreds of boards. > > So, send a patch! OK, so with the intention of "need to light a fire", consider the fire lit! But, I think v2 of this series needs to: - Address the bug that's been noted of you checking on "DM_BLK" when it's really just "BLK". - Do a test build with BLK just being unconditional now. For example, you're deleting the am335x_evm family but it builds fine with BLK being enabled now. I even gave it a run time test via test.py and we're fine. So, I think a new run where you see what fails to build with BLK enabled by default now is in order to come up with a new delete list. Thanks!
On Mon, Nov 19, 2018 at 12:36 PM Tom Rini <trini@konsulko.com> wrote: > > On Mon, Nov 19, 2018 at 10:54 AM Simon Glass <sjg@chromium.org> wrote: > > > > All boards should now be migrated to use CONFIG_BLK. This series removes > > those with build problems using this option. > > > > If maintainers want to keep these boards in they should send a patch in > > the next week or two. Otherwise the board will be removed in the next > > release, and will need to be added and re-reviewed later. > > > > The goal is to have all boards use driver model. But so far, we do allow > > CONFIG_DM to not be defined. > > > > PLEASE NOTE: This is not an easy process. It is possible that your board > > does work, or works with only minor changes. Please try to understand that > > the removal of a board is not done because people don't like your board. > > In fact the board might have been the first one I used when trying out > > U-Boot! It's just that we expect maintainers to keep up with the migration > > to driver model which has been running now for 4 years. It just isn't > > possible for a few people to migrate and test hundreds of boards. > > > > So, send a patch! > > OK, so with the intention of "need to light a fire", consider the fire > lit! But, I think v2 of this series needs to: > - Address the bug that's been noted of you checking on "DM_BLK" when > it's really just "BLK". > - Do a test build with BLK just being unconditional now. For example, > you're deleting the am335x_evm family but it builds fine with BLK > being enabled now. I even gave it a run time test via test.py and > we're fine. So, I think a new run where you see what fails to build > with BLK enabled by default now is in order to come up with a new > delete list. > When we were migrating toward GCC 6, we introduced a warning message that was displayed at build indicating older versions of GCC would be unsupported, and GCC 6 would become a requirement. The CONFIG_DM_I2C_COMPAT generates a build warning and suggests that it be removed. I would like to propose that in the future, when setting deadlines, we insert something into the build mechanism that generates a warning to tell people that something is going to happen. Just my 2-cents. adam > Thanks! > > -- > Tom
On 11/19/2018 08:45 PM, Adam Ford wrote: > On Mon, Nov 19, 2018 at 12:36 PM Tom Rini <trini@konsulko.com> wrote: >> >> On Mon, Nov 19, 2018 at 10:54 AM Simon Glass <sjg@chromium.org> wrote: >>> >>> All boards should now be migrated to use CONFIG_BLK. This series removes >>> those with build problems using this option. >>> >>> If maintainers want to keep these boards in they should send a patch in >>> the next week or two. Otherwise the board will be removed in the next >>> release, and will need to be added and re-reviewed later. >>> >>> The goal is to have all boards use driver model. But so far, we do allow >>> CONFIG_DM to not be defined. >>> >>> PLEASE NOTE: This is not an easy process. It is possible that your board >>> does work, or works with only minor changes. Please try to understand that >>> the removal of a board is not done because people don't like your board. >>> In fact the board might have been the first one I used when trying out >>> U-Boot! It's just that we expect maintainers to keep up with the migration >>> to driver model which has been running now for 4 years. It just isn't >>> possible for a few people to migrate and test hundreds of boards. >>> >>> So, send a patch! >> >> OK, so with the intention of "need to light a fire", consider the fire >> lit! But, I think v2 of this series needs to: >> - Address the bug that's been noted of you checking on "DM_BLK" when >> it's really just "BLK". >> - Do a test build with BLK just being unconditional now. For example, >> you're deleting the am335x_evm family but it builds fine with BLK >> being enabled now. I even gave it a run time test via test.py and >> we're fine. So, I think a new run where you see what fails to build >> with BLK enabled by default now is in order to come up with a new >> delete list. >> > > When we were migrating toward GCC 6, we introduced a warning message > that was displayed at build indicating older versions of GCC would be > unsupported, and GCC 6 would become a requirement. The > CONFIG_DM_I2C_COMPAT generates a build warning and suggests that it be > removed. I would like to propose that in the future, when setting > deadlines, we insert something into the build mechanism that generates > a warning to tell people that something is going to happen. I agree, that sounds good. I am extremely unhappy by how Simon decided, unilaterally, some arbitrary deadline, told pretty much no one about that deadline and then put a knife on many peoples' throats by sending out this series which removes boards that are actively used and maintained, demanding they be converted right this instant. In my opinion, most maintainers cannot just drop everything they are working on at any given point and start doing random conversion the minute Simon decides they should. The only result of such behavior will be loss of functionality and more stress exerted on the maintainers, which helps no one. While I understand the need to move over to CONFIG_DM_BLK, U-Boot is a cooperative project and it can only move forward as fast as the community around it can. If anyone within that community wants to convert others to some new feature, that's perfectly fine, but there should be a clear way to do it and a possibility to shift a deadline for conversion around for boards which are useful to people and simply late. Just dropping useful functionality is not acceptable.
On Mon, Nov 19, 2018 at 10:32:01PM +0100, Marek Vasut wrote: > On 11/19/2018 08:45 PM, Adam Ford wrote: > > On Mon, Nov 19, 2018 at 12:36 PM Tom Rini <trini@konsulko.com> wrote: > >> > >> On Mon, Nov 19, 2018 at 10:54 AM Simon Glass <sjg@chromium.org> wrote: > >>> > >>> All boards should now be migrated to use CONFIG_BLK. This series removes > >>> those with build problems using this option. > >>> > >>> If maintainers want to keep these boards in they should send a patch in > >>> the next week or two. Otherwise the board will be removed in the next > >>> release, and will need to be added and re-reviewed later. > >>> > >>> The goal is to have all boards use driver model. But so far, we do allow > >>> CONFIG_DM to not be defined. > >>> > >>> PLEASE NOTE: This is not an easy process. It is possible that your board > >>> does work, or works with only minor changes. Please try to understand that > >>> the removal of a board is not done because people don't like your board. > >>> In fact the board might have been the first one I used when trying out > >>> U-Boot! It's just that we expect maintainers to keep up with the migration > >>> to driver model which has been running now for 4 years. It just isn't > >>> possible for a few people to migrate and test hundreds of boards. > >>> > >>> So, send a patch! > >> > >> OK, so with the intention of "need to light a fire", consider the fire > >> lit! But, I think v2 of this series needs to: > >> - Address the bug that's been noted of you checking on "DM_BLK" when > >> it's really just "BLK". > >> - Do a test build with BLK just being unconditional now. For example, > >> you're deleting the am335x_evm family but it builds fine with BLK > >> being enabled now. I even gave it a run time test via test.py and > >> we're fine. So, I think a new run where you see what fails to build > >> with BLK enabled by default now is in order to come up with a new > >> delete list. > >> > > > > When we were migrating toward GCC 6, we introduced a warning message > > that was displayed at build indicating older versions of GCC would be > > unsupported, and GCC 6 would become a requirement. The > > CONFIG_DM_I2C_COMPAT generates a build warning and suggests that it be > > removed. I would like to propose that in the future, when setting > > deadlines, we insert something into the build mechanism that generates > > a warning to tell people that something is going to happen. > > I agree, that sounds good. > > I am extremely unhappy by how Simon decided, unilaterally, some > arbitrary deadline, told pretty much no one about that deadline and then > put a knife on many peoples' throats by sending out this series which > removes boards that are actively used and maintained, demanding they be > converted right this instant. OK, lets step back for a moment. Part of the problem is that yes, we (I) never found a good way to make a big scary build warning happen. But, lets look at https://patchwork.ozlabs.org/patch/798309/ for a moment, which is when we set this deadline, and we had a good bit of discussion about related issues to make it happen. I also know that around the v2018.05 release I said, in public, but no I can't find a link right this moment, that we were pushing off a little bit on dropping _everything_ right then as there was basically some fairly important / widely used USB stuff that hadn't been converted yet (which has since been, I think, otherwise am335x_evm & co wouldn't have been happy?). I know I did since I can see in the archives a number of series where maintainers did a bunch of changes to various platforms / SoCs to turn on BLK right then. So, no, I don't want to drop a bunch of platforms _right_now_. But we really need to see what doesn't link anymore with BLK forced on, and plan from there.
Hi, On Mon, 19 Nov 2018 at 14:54, Tom Rini <trini@konsulko.com> wrote: > > On Mon, Nov 19, 2018 at 10:32:01PM +0100, Marek Vasut wrote: > > On 11/19/2018 08:45 PM, Adam Ford wrote: > > > On Mon, Nov 19, 2018 at 12:36 PM Tom Rini <trini@konsulko.com> wrote: > > >> > > >> On Mon, Nov 19, 2018 at 10:54 AM Simon Glass <sjg@chromium.org> wrote: > > >>> > > >>> All boards should now be migrated to use CONFIG_BLK. This series removes > > >>> those with build problems using this option. > > >>> > > >>> If maintainers want to keep these boards in they should send a patch in > > >>> the next week or two. Otherwise the board will be removed in the next > > >>> release, and will need to be added and re-reviewed later. > > >>> > > >>> The goal is to have all boards use driver model. But so far, we do allow > > >>> CONFIG_DM to not be defined. > > >>> > > >>> PLEASE NOTE: This is not an easy process. It is possible that your board > > >>> does work, or works with only minor changes. Please try to understand that > > >>> the removal of a board is not done because people don't like your board. > > >>> In fact the board might have been the first one I used when trying out > > >>> U-Boot! It's just that we expect maintainers to keep up with the migration > > >>> to driver model which has been running now for 4 years. It just isn't > > >>> possible for a few people to migrate and test hundreds of boards. > > >>> > > >>> So, send a patch! > > >> > > >> OK, so with the intention of "need to light a fire", consider the fire > > >> lit! But, I think v2 of this series needs to: > > >> - Address the bug that's been noted of you checking on "DM_BLK" when > > >> it's really just "BLK". > > >> - Do a test build with BLK just being unconditional now. For example, > > >> you're deleting the am335x_evm family but it builds fine with BLK > > >> being enabled now. I even gave it a run time test via test.py and > > >> we're fine. So, I think a new run where you see what fails to build > > >> with BLK enabled by default now is in order to come up with a new > > >> delete list. > > >> > > > > > > When we were migrating toward GCC 6, we introduced a warning message > > > that was displayed at build indicating older versions of GCC would be > > > unsupported, and GCC 6 would become a requirement. The > > > CONFIG_DM_I2C_COMPAT generates a build warning and suggests that it be > > > removed. I would like to propose that in the future, when setting > > > deadlines, we insert something into the build mechanism that generates > > > a warning to tell people that something is going to happen. > > > > I agree, that sounds good. > > > > I am extremely unhappy by how Simon decided, unilaterally, some > > arbitrary deadline, told pretty much no one about that deadline and then > > put a knife on many peoples' throats by sending out this series which > > removes boards that are actively used and maintained, demanding they be > > converted right this instant. > > OK, lets step back for a moment. Part of the problem is that yes, we > (I) never found a good way to make a big scary build warning happen. > But, lets look at https://patchwork.ozlabs.org/patch/798309/ for a > moment, which is when we set this deadline, and we had a good bit of > discussion about related issues to make it happen. > > I also know that around the v2018.05 release I said, in public, but no I > can't find a link right this moment, that we were pushing off a little > bit on dropping _everything_ right then as there was basically some > fairly important / widely used USB stuff that hadn't been converted yet > (which has since been, I think, otherwise am335x_evm & co wouldn't have > been happy?). I know I did since I can see in the archives a number of > series where maintainers did a bunch of changes to various platforms / > SoCs to turn on BLK right then. > > So, no, I don't want to drop a bunch of platforms _right_now_. But we > really need to see what doesn't link anymore with BLK forced on, and > plan from there. 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. Regards, Simon
On Mon, Nov 19, 2018 at 3:54 PM Tom Rini <trini@konsulko.com> wrote: > > On Mon, Nov 19, 2018 at 10:32:01PM +0100, Marek Vasut wrote: > > On 11/19/2018 08:45 PM, Adam Ford wrote: > > > On Mon, Nov 19, 2018 at 12:36 PM Tom Rini <trini@konsulko.com> wrote: > > >> > > >> On Mon, Nov 19, 2018 at 10:54 AM Simon Glass <sjg@chromium.org> wrote: > > >>> > > >>> All boards should now be migrated to use CONFIG_BLK. This series removes > > >>> those with build problems using this option. > > >>> > > >>> If maintainers want to keep these boards in they should send a patch in > > >>> the next week or two. Otherwise the board will be removed in the next > > >>> release, and will need to be added and re-reviewed later. > > >>> > > >>> The goal is to have all boards use driver model. But so far, we do allow > > >>> CONFIG_DM to not be defined. > > >>> > > >>> PLEASE NOTE: This is not an easy process. It is possible that your board > > >>> does work, or works with only minor changes. Please try to understand that > > >>> the removal of a board is not done because people don't like your board. > > >>> In fact the board might have been the first one I used when trying out > > >>> U-Boot! It's just that we expect maintainers to keep up with the migration > > >>> to driver model which has been running now for 4 years. It just isn't > > >>> possible for a few people to migrate and test hundreds of boards. > > >>> > > >>> So, send a patch! > > >> > > >> OK, so with the intention of "need to light a fire", consider the fire > > >> lit! But, I think v2 of this series needs to: > > >> - Address the bug that's been noted of you checking on "DM_BLK" when > > >> it's really just "BLK". > > >> - Do a test build with BLK just being unconditional now. For example, > > >> you're deleting the am335x_evm family but it builds fine with BLK > > >> being enabled now. I even gave it a run time test via test.py and > > >> we're fine. So, I think a new run where you see what fails to build > > >> with BLK enabled by default now is in order to come up with a new > > >> delete list. > > >> > > > > > > When we were migrating toward GCC 6, we introduced a warning message > > > that was displayed at build indicating older versions of GCC would be > > > unsupported, and GCC 6 would become a requirement. The > > > CONFIG_DM_I2C_COMPAT generates a build warning and suggests that it be > > > removed. I would like to propose that in the future, when setting > > > deadlines, we insert something into the build mechanism that generates > > > a warning to tell people that something is going to happen. > > > > I agree, that sounds good. > > > > I am extremely unhappy by how Simon decided, unilaterally, some > > arbitrary deadline, told pretty much no one about that deadline and then > > put a knife on many peoples' throats by sending out this series which > > removes boards that are actively used and maintained, demanding they be > > converted right this instant. > > OK, lets step back for a moment. Part of the problem is that yes, we > (I) never found a good way to make a big scary build warning happen. > But, lets look at https://patchwork.ozlabs.org/patch/798309/ for a > moment, which is when we set this deadline, and we had a good bit of > discussion about related issues to make it happen. > > I also know that around the v2018.05 release I said, in public, but no I > can't find a link right this moment, that we were pushing off a little > bit on dropping _everything_ right then as there was basically some > fairly important / widely used USB stuff that hadn't been converted yet > (which has since been, I think, otherwise am335x_evm & co wouldn't have > been happy?). I know I did since I can see in the archives a number of > series where maintainers did a bunch of changes to various platforms / > SoCs to turn on BLK right then. > > So, no, I don't want to drop a bunch of platforms _right_now_. But we > really need to see what doesn't link anymore with BLK forced on, and > plan from there. I remember the discussion, but it seems rather arbitrary for one person to unilaterally start deleting boards. I think a more appropriate approach would be to start a dialog instead of deleting boards and then giving people a fairly short notice to respond - especially this close to the US Thanksgiving holiday, several religious holidays and New Years. Many people have planed time off and/or end-of-year deadlines to hit without getting an abrupt suprise. adam > > -- > Tom
On 11/19/2018 10:54 PM, Tom Rini wrote: > On Mon, Nov 19, 2018 at 10:32:01PM +0100, Marek Vasut wrote: >> On 11/19/2018 08:45 PM, Adam Ford wrote: >>> On Mon, Nov 19, 2018 at 12:36 PM Tom Rini <trini@konsulko.com> wrote: >>>> >>>> On Mon, Nov 19, 2018 at 10:54 AM Simon Glass <sjg@chromium.org> wrote: >>>>> >>>>> All boards should now be migrated to use CONFIG_BLK. This series removes >>>>> those with build problems using this option. >>>>> >>>>> If maintainers want to keep these boards in they should send a patch in >>>>> the next week or two. Otherwise the board will be removed in the next >>>>> release, and will need to be added and re-reviewed later. >>>>> >>>>> The goal is to have all boards use driver model. But so far, we do allow >>>>> CONFIG_DM to not be defined. >>>>> >>>>> PLEASE NOTE: This is not an easy process. It is possible that your board >>>>> does work, or works with only minor changes. Please try to understand that >>>>> the removal of a board is not done because people don't like your board. >>>>> In fact the board might have been the first one I used when trying out >>>>> U-Boot! It's just that we expect maintainers to keep up with the migration >>>>> to driver model which has been running now for 4 years. It just isn't >>>>> possible for a few people to migrate and test hundreds of boards. >>>>> >>>>> So, send a patch! >>>> >>>> OK, so with the intention of "need to light a fire", consider the fire >>>> lit! But, I think v2 of this series needs to: >>>> - Address the bug that's been noted of you checking on "DM_BLK" when >>>> it's really just "BLK". >>>> - Do a test build with BLK just being unconditional now. For example, >>>> you're deleting the am335x_evm family but it builds fine with BLK >>>> being enabled now. I even gave it a run time test via test.py and >>>> we're fine. So, I think a new run where you see what fails to build >>>> with BLK enabled by default now is in order to come up with a new >>>> delete list. >>>> >>> >>> When we were migrating toward GCC 6, we introduced a warning message >>> that was displayed at build indicating older versions of GCC would be >>> unsupported, and GCC 6 would become a requirement. The >>> CONFIG_DM_I2C_COMPAT generates a build warning and suggests that it be >>> removed. I would like to propose that in the future, when setting >>> deadlines, we insert something into the build mechanism that generates >>> a warning to tell people that something is going to happen. >> >> I agree, that sounds good. >> >> I am extremely unhappy by how Simon decided, unilaterally, some >> arbitrary deadline, told pretty much no one about that deadline and then >> put a knife on many peoples' throats by sending out this series which >> removes boards that are actively used and maintained, demanding they be >> converted right this instant. > > OK, lets step back for a moment. Part of the problem is that yes, we > (I) never found a good way to make a big scary build warning happen. > But, lets look at https://patchwork.ozlabs.org/patch/798309/ for a > moment, which is when we set this deadline, and we had a good bit of > discussion about related issues to make it happen. > > I also know that around the v2018.05 release I said, in public, but no I > can't find a link right this moment, that we were pushing off a little > bit on dropping _everything_ right then as there was basically some > fairly important / widely used USB stuff that hadn't been converted yet > (which has since been, I think, otherwise am335x_evm & co wouldn't have > been happy?). I know I did since I can see in the archives a number of > series where maintainers did a bunch of changes to various platforms / > SoCs to turn on BLK right then. > > So, no, I don't want to drop a bunch of platforms _right_now_. But we > really need to see what doesn't link anymore with BLK forced on, and > plan from there. If we have a list of boards which do not build and their maintainers are notified reasonable in advance, that is fine by me. A Makefile warning is good IMO.
On 11/19/2018 11:02 PM, Adam Ford wrote: > On Mon, Nov 19, 2018 at 3:54 PM Tom Rini <trini@konsulko.com> wrote: >> >> On Mon, Nov 19, 2018 at 10:32:01PM +0100, Marek Vasut wrote: >>> On 11/19/2018 08:45 PM, Adam Ford wrote: >>>> On Mon, Nov 19, 2018 at 12:36 PM Tom Rini <trini@konsulko.com> wrote: >>>>> >>>>> On Mon, Nov 19, 2018 at 10:54 AM Simon Glass <sjg@chromium.org> wrote: >>>>>> >>>>>> All boards should now be migrated to use CONFIG_BLK. This series removes >>>>>> those with build problems using this option. >>>>>> >>>>>> If maintainers want to keep these boards in they should send a patch in >>>>>> the next week or two. Otherwise the board will be removed in the next >>>>>> release, and will need to be added and re-reviewed later. >>>>>> >>>>>> The goal is to have all boards use driver model. But so far, we do allow >>>>>> CONFIG_DM to not be defined. >>>>>> >>>>>> PLEASE NOTE: This is not an easy process. It is possible that your board >>>>>> does work, or works with only minor changes. Please try to understand that >>>>>> the removal of a board is not done because people don't like your board. >>>>>> In fact the board might have been the first one I used when trying out >>>>>> U-Boot! It's just that we expect maintainers to keep up with the migration >>>>>> to driver model which has been running now for 4 years. It just isn't >>>>>> possible for a few people to migrate and test hundreds of boards. >>>>>> >>>>>> So, send a patch! >>>>> >>>>> OK, so with the intention of "need to light a fire", consider the fire >>>>> lit! But, I think v2 of this series needs to: >>>>> - Address the bug that's been noted of you checking on "DM_BLK" when >>>>> it's really just "BLK". >>>>> - Do a test build with BLK just being unconditional now. For example, >>>>> you're deleting the am335x_evm family but it builds fine with BLK >>>>> being enabled now. I even gave it a run time test via test.py and >>>>> we're fine. So, I think a new run where you see what fails to build >>>>> with BLK enabled by default now is in order to come up with a new >>>>> delete list. >>>>> >>>> >>>> When we were migrating toward GCC 6, we introduced a warning message >>>> that was displayed at build indicating older versions of GCC would be >>>> unsupported, and GCC 6 would become a requirement. The >>>> CONFIG_DM_I2C_COMPAT generates a build warning and suggests that it be >>>> removed. I would like to propose that in the future, when setting >>>> deadlines, we insert something into the build mechanism that generates >>>> a warning to tell people that something is going to happen. >>> >>> I agree, that sounds good. >>> >>> I am extremely unhappy by how Simon decided, unilaterally, some >>> arbitrary deadline, told pretty much no one about that deadline and then >>> put a knife on many peoples' throats by sending out this series which >>> removes boards that are actively used and maintained, demanding they be >>> converted right this instant. >> >> OK, lets step back for a moment. Part of the problem is that yes, we >> (I) never found a good way to make a big scary build warning happen. >> But, lets look at https://patchwork.ozlabs.org/patch/798309/ for a >> moment, which is when we set this deadline, and we had a good bit of >> discussion about related issues to make it happen. >> >> I also know that around the v2018.05 release I said, in public, but no I >> can't find a link right this moment, that we were pushing off a little >> bit on dropping _everything_ right then as there was basically some >> fairly important / widely used USB stuff that hadn't been converted yet >> (which has since been, I think, otherwise am335x_evm & co wouldn't have >> been happy?). I know I did since I can see in the archives a number of >> series where maintainers did a bunch of changes to various platforms / >> SoCs to turn on BLK right then. >> >> So, no, I don't want to drop a bunch of platforms _right_now_. But we >> really need to see what doesn't link anymore with BLK forced on, and >> plan from there. > > I remember the discussion, but it seems rather arbitrary for one > person to unilaterally start deleting boards. I think a more > appropriate approach would be to start a dialog instead of deleting > boards and then giving people a fairly short notice to respond - > especially this close to the US Thanksgiving holiday, several > religious holidays and New Years. Many people have planed time off > and/or end-of-year deadlines to hit without getting an abrupt suprise. ACK
Hi, On 19/11/18 23:06, Marek Vasut wrote: > On 11/19/2018 11:02 PM, Adam Ford wrote: >> On Mon, Nov 19, 2018 at 3:54 PM Tom Rini <trini@konsulko.com> wrote: >>> >>> On Mon, Nov 19, 2018 at 10:32:01PM +0100, Marek Vasut wrote: >>>> On 11/19/2018 08:45 PM, Adam Ford wrote: >>>>> On Mon, Nov 19, 2018 at 12:36 PM Tom Rini <trini@konsulko.com> wrote: >>>>>> >>>>>> On Mon, Nov 19, 2018 at 10:54 AM Simon Glass <sjg@chromium.org> wrote: >>>>>>> >>>>>>> All boards should now be migrated to use CONFIG_BLK. This series removes >>>>>>> those with build problems using this option. >>>>>>> >>>>>>> If maintainers want to keep these boards in they should send a patch in >>>>>>> the next week or two. Otherwise the board will be removed in the next >>>>>>> release, and will need to be added and re-reviewed later. >>>>>>> >>>>>>> The goal is to have all boards use driver model. But so far, we do allow >>>>>>> CONFIG_DM to not be defined. >>>>>>> >>>>>>> PLEASE NOTE: This is not an easy process. It is possible that your board >>>>>>> does work, or works with only minor changes. Please try to understand that >>>>>>> the removal of a board is not done because people don't like your board. >>>>>>> In fact the board might have been the first one I used when trying out >>>>>>> U-Boot! It's just that we expect maintainers to keep up with the migration >>>>>>> to driver model which has been running now for 4 years. It just isn't >>>>>>> possible for a few people to migrate and test hundreds of boards. >>>>>>> >>>>>>> So, send a patch! >>>>>> >>>>>> OK, so with the intention of "need to light a fire", consider the fire >>>>>> lit! But, I think v2 of this series needs to: >>>>>> - Address the bug that's been noted of you checking on "DM_BLK" when >>>>>> it's really just "BLK". >>>>>> - Do a test build with BLK just being unconditional now. For example, >>>>>> you're deleting the am335x_evm family but it builds fine with BLK >>>>>> being enabled now. I even gave it a run time test via test.py and >>>>>> we're fine. So, I think a new run where you see what fails to build >>>>>> with BLK enabled by default now is in order to come up with a new >>>>>> delete list. >>>>>> >>>>> >>>>> When we were migrating toward GCC 6, we introduced a warning message >>>>> that was displayed at build indicating older versions of GCC would be >>>>> unsupported, and GCC 6 would become a requirement. The >>>>> CONFIG_DM_I2C_COMPAT generates a build warning and suggests that it be >>>>> removed. I would like to propose that in the future, when setting >>>>> deadlines, we insert something into the build mechanism that generates >>>>> a warning to tell people that something is going to happen. >>>> >>>> I agree, that sounds good. >>>> >>>> I am extremely unhappy by how Simon decided, unilaterally, some >>>> arbitrary deadline, told pretty much no one about that deadline and then >>>> put a knife on many peoples' throats by sending out this series which >>>> removes boards that are actively used and maintained, demanding they be >>>> converted right this instant. >>> >>> OK, lets step back for a moment. Part of the problem is that yes, we >>> (I) never found a good way to make a big scary build warning happen. >>> But, lets look at https://patchwork.ozlabs.org/patch/798309/ for a >>> moment, which is when we set this deadline, and we had a good bit of >>> discussion about related issues to make it happen. >>> >>> I also know that around the v2018.05 release I said, in public, but no I >>> can't find a link right this moment, that we were pushing off a little >>> bit on dropping _everything_ right then as there was basically some >>> fairly important / widely used USB stuff that hadn't been converted yet >>> (which has since been, I think, otherwise am335x_evm & co wouldn't have >>> been happy?). I know I did since I can see in the archives a number of >>> series where maintainers did a bunch of changes to various platforms / >>> SoCs to turn on BLK right then. >>> >>> So, no, I don't want to drop a bunch of platforms _right_now_. But we >>> really need to see what doesn't link anymore with BLK forced on, and >>> plan from there. >> >> I remember the discussion, but it seems rather arbitrary for one >> person to unilaterally start deleting boards. I think a more >> appropriate approach would be to start a dialog instead of deleting >> boards and then giving people a fairly short notice to respond - >> especially this close to the US Thanksgiving holiday, several >> religious holidays and New Years. Many people have planed time off >> and/or end-of-year deadlines to hit without getting an abrupt suprise. > > ACK I fully agree with Marek and Adam, but I have also some other technical points related to i.MX6. I agree to move to new and better code, but this should not drop important features that are appreciated by customers. Up now, U-Boot as project was pretty conservative, trying t osupport as far as it is possible even older architectures (MPC 88x, for example). On i.MX6, a feature is to have a single U-Boot binary (SPL + U-Boot) running for more variants (Quad / Dual / Solo) of the SOC. This is done with run time detection in code (SPL) - macros are provide to make the work easy (it is, currently). There are plenty of boards doing this (all listed by Simon for removal). This is common if the board has a SOM, and of course the SOM is sold in different variants with different prices. If I understand well, moving to CONFIG_BLK means enabling CONFIG_DM_MMC and this requires to set a DTS. But a DT is compiled by DTC, that means we have a DT for each variant of the SOC. This forbids to have a single binary and we need different binaries, one for each variant. We lose an important feature, at least for some boards. Agree that having DT is nice, but this should not drop what customer are asking. I know there are some improvement in TI code to get the root node in DT and then load from it. Anyway, specially for i.MX6 solo, we are quite running out of space in SRAM, mainly due to other required features. And having multiple DTB with CONFIG_MULTI_DTB_FIT seems to work just if we have no SPL. So first, it looks like that the issue is not so trivial as it was, and second a technical solution must be searched for that. Best regards, Stefano Babic
On Tue, Nov 20, 2018 at 12:32 PM Stefano Babic <sbabic@denx.de> wrote: > > Hi, > > On 19/11/18 23:06, Marek Vasut wrote: > > On 11/19/2018 11:02 PM, Adam Ford wrote: > >> On Mon, Nov 19, 2018 at 3:54 PM Tom Rini <trini@konsulko.com> wrote: > >>> > >>> On Mon, Nov 19, 2018 at 10:32:01PM +0100, Marek Vasut wrote: > >>>> On 11/19/2018 08:45 PM, Adam Ford wrote: > >>>>> On Mon, Nov 19, 2018 at 12:36 PM Tom Rini <trini@konsulko.com> wrote: > >>>>>> > >>>>>> On Mon, Nov 19, 2018 at 10:54 AM Simon Glass <sjg@chromium.org> wrote: > >>>>>>> > >>>>>>> All boards should now be migrated to use CONFIG_BLK. This series removes > >>>>>>> those with build problems using this option. > >>>>>>> > >>>>>>> If maintainers want to keep these boards in they should send a patch in > >>>>>>> the next week or two. Otherwise the board will be removed in the next > >>>>>>> release, and will need to be added and re-reviewed later. > >>>>>>> > >>>>>>> The goal is to have all boards use driver model. But so far, we do allow > >>>>>>> CONFIG_DM to not be defined. > >>>>>>> > >>>>>>> PLEASE NOTE: This is not an easy process. It is possible that your board > >>>>>>> does work, or works with only minor changes. Please try to understand that > >>>>>>> the removal of a board is not done because people don't like your board. > >>>>>>> In fact the board might have been the first one I used when trying out > >>>>>>> U-Boot! It's just that we expect maintainers to keep up with the migration > >>>>>>> to driver model which has been running now for 4 years. It just isn't > >>>>>>> possible for a few people to migrate and test hundreds of boards. > >>>>>>> > >>>>>>> So, send a patch! > >>>>>> > >>>>>> OK, so with the intention of "need to light a fire", consider the fire > >>>>>> lit! But, I think v2 of this series needs to: > >>>>>> - Address the bug that's been noted of you checking on "DM_BLK" when > >>>>>> it's really just "BLK". > >>>>>> - Do a test build with BLK just being unconditional now. For example, > >>>>>> you're deleting the am335x_evm family but it builds fine with BLK > >>>>>> being enabled now. I even gave it a run time test via test.py and > >>>>>> we're fine. So, I think a new run where you see what fails to build > >>>>>> with BLK enabled by default now is in order to come up with a new > >>>>>> delete list. > >>>>>> > >>>>> > >>>>> When we were migrating toward GCC 6, we introduced a warning message > >>>>> that was displayed at build indicating older versions of GCC would be > >>>>> unsupported, and GCC 6 would become a requirement. The > >>>>> CONFIG_DM_I2C_COMPAT generates a build warning and suggests that it be > >>>>> removed. I would like to propose that in the future, when setting > >>>>> deadlines, we insert something into the build mechanism that generates > >>>>> a warning to tell people that something is going to happen. > >>>> > >>>> I agree, that sounds good. > >>>> > >>>> I am extremely unhappy by how Simon decided, unilaterally, some > >>>> arbitrary deadline, told pretty much no one about that deadline and then > >>>> put a knife on many peoples' throats by sending out this series which > >>>> removes boards that are actively used and maintained, demanding they be > >>>> converted right this instant. > >>> > >>> OK, lets step back for a moment. Part of the problem is that yes, we > >>> (I) never found a good way to make a big scary build warning happen. > >>> But, lets look at https://patchwork.ozlabs.org/patch/798309/ for a > >>> moment, which is when we set this deadline, and we had a good bit of > >>> discussion about related issues to make it happen. > >>> > >>> I also know that around the v2018.05 release I said, in public, but no I > >>> can't find a link right this moment, that we were pushing off a little > >>> bit on dropping _everything_ right then as there was basically some > >>> fairly important / widely used USB stuff that hadn't been converted yet > >>> (which has since been, I think, otherwise am335x_evm & co wouldn't have > >>> been happy?). I know I did since I can see in the archives a number of > >>> series where maintainers did a bunch of changes to various platforms / > >>> SoCs to turn on BLK right then. > >>> > >>> So, no, I don't want to drop a bunch of platforms _right_now_. But we > >>> really need to see what doesn't link anymore with BLK forced on, and > >>> plan from there. > >> > >> I remember the discussion, but it seems rather arbitrary for one > >> person to unilaterally start deleting boards. I think a more > >> appropriate approach would be to start a dialog instead of deleting > >> boards and then giving people a fairly short notice to respond - > >> especially this close to the US Thanksgiving holiday, several > >> religious holidays and New Years. Many people have planed time off > >> and/or end-of-year deadlines to hit without getting an abrupt suprise. > > > > ACK > > > I fully agree with Marek and Adam, but I have also some other technical > points related to i.MX6. > > I agree to move to new and better code, but this should not drop > important features that are appreciated by customers. Up now, U-Boot as > project was pretty conservative, trying t osupport as far as it is > possible even older architectures (MPC 88x, for example). > > On i.MX6, a feature is to have a single U-Boot binary (SPL + U-Boot) > running for more variants (Quad / Dual / Solo) of the SOC. This is done > with run time detection in code (SPL) - macros are provide to make the > work easy (it is, currently). There are plenty of boards doing this (all > listed by Simon for removal). This is common if the board has a SOM, and > of course the SOM is sold in different variants with different prices. > > If I understand well, moving to CONFIG_BLK means enabling CONFIG_DM_MMC > and this requires to set a DTS. But a DT is compiled by DTC, that means > we have a DT for each variant of the SOC. This forbids to have a single > binary and we need different binaries, one for each variant. We lose an > important feature, at least for some boards. Agree that having DT is > nice, but this should not drop what customer are asking. > > I know there are some improvement in TI code to get the root node in DT > and then load from it. Anyway, specially for i.MX6 solo, we are quite > running out of space in SRAM, mainly due to other required features. And > having multiple DTB with CONFIG_MULTI_DTB_FIT seems to work just if we > have no SPL. > > So first, it looks like that the issue is not so trivial as it was, and > second a technical solution must be searched for that. There's a few configs that handle multiple DT, and other things like ATF, with a SPL+FIT combination, one example is pine64_plus_defconfig
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? 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? Regards, Soeren > 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 >
On Tue, Nov 20, 2018 at 01:42:15PM +0100, Soeren Moch wrote: > > > 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. > 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.
On 11/20/2018 02:37 PM, Tom Rini wrote: > On Tue, Nov 20, 2018 at 01:42:15PM +0100, Soeren Moch wrote: >> >> >> 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. > >> 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. Build time warning for a year would be good ? Maybe we need some generic Makefile macro to set those up.
On Tue, Nov 20, 2018 at 02:40:43PM +0100, Marek Vasut wrote: > On 11/20/2018 02:37 PM, Tom Rini wrote: > > On Tue, Nov 20, 2018 at 01:42:15PM +0100, Soeren Moch wrote: > >> > >> > >> 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. > > > >> 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. > > 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. > 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.
On 11/20/2018 02:42 PM, Tom Rini wrote: > On Tue, Nov 20, 2018 at 02:40:43PM +0100, Marek Vasut wrote: >> On 11/20/2018 02:37 PM, Tom Rini wrote: >>> On Tue, Nov 20, 2018 at 01:42:15PM +0100, Soeren Moch wrote: >>>> >>>> >>>> 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. >>> >>>> 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. >> >> 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. >> 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.
On Tue, Nov 20, 2018 at 02:45:24PM +0100, Marek Vasut wrote: > On 11/20/2018 02:42 PM, Tom Rini wrote: > > On Tue, Nov 20, 2018 at 02:40:43PM +0100, Marek Vasut wrote: > >> On 11/20/2018 02:37 PM, Tom Rini wrote: > >>> On Tue, Nov 20, 2018 at 01:42:15PM +0100, Soeren Moch wrote: > >>>> > >>>> > >>>> 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. > >>> > >>>> 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. > >> > >> 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. > >> 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).
On 11/20/2018 02:53 PM, Tom Rini wrote: > On Tue, Nov 20, 2018 at 02:45:24PM +0100, Marek Vasut wrote: >> On 11/20/2018 02:42 PM, Tom Rini wrote: >>> On Tue, Nov 20, 2018 at 02:40:43PM +0100, Marek Vasut wrote: >>>> On 11/20/2018 02:37 PM, Tom Rini wrote: >>>>> On Tue, Nov 20, 2018 at 01:42:15PM +0100, Soeren Moch wrote: >>>>>> >>>>>> >>>>>> 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. >>>>> >>>>>> 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. >>>> >>>> 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. Sounds good. >>>> 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). I think the Makefile noise would be good. It'd be annoying enough and persistently remind people to fix their stuff.
(massively trimmed cc list, leaving the current sunxi custodians and Hans who is a fellow emeritus custodian) On Mon, 2018-11-19 at 14:58 -0700, Simon Glass wrote: > 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? Ian.
On Tue, Nov 20, 2018 at 12:00:13PM +0100, Stefano Babic wrote: > Hi, > > On 19/11/18 23:06, Marek Vasut wrote: > > On 11/19/2018 11:02 PM, Adam Ford wrote: > >> On Mon, Nov 19, 2018 at 3:54 PM Tom Rini <trini@konsulko.com> wrote: > >>> > >>> On Mon, Nov 19, 2018 at 10:32:01PM +0100, Marek Vasut wrote: > >>>> On 11/19/2018 08:45 PM, Adam Ford wrote: > >>>>> On Mon, Nov 19, 2018 at 12:36 PM Tom Rini <trini@konsulko.com> wrote: > >>>>>> > >>>>>> On Mon, Nov 19, 2018 at 10:54 AM Simon Glass <sjg@chromium.org> wrote: > >>>>>>> > >>>>>>> All boards should now be migrated to use CONFIG_BLK. This series removes > >>>>>>> those with build problems using this option. > >>>>>>> > >>>>>>> If maintainers want to keep these boards in they should send a patch in > >>>>>>> the next week or two. Otherwise the board will be removed in the next > >>>>>>> release, and will need to be added and re-reviewed later. > >>>>>>> > >>>>>>> The goal is to have all boards use driver model. But so far, we do allow > >>>>>>> CONFIG_DM to not be defined. > >>>>>>> > >>>>>>> PLEASE NOTE: This is not an easy process. It is possible that your board > >>>>>>> does work, or works with only minor changes. Please try to understand that > >>>>>>> the removal of a board is not done because people don't like your board. > >>>>>>> In fact the board might have been the first one I used when trying out > >>>>>>> U-Boot! It's just that we expect maintainers to keep up with the migration > >>>>>>> to driver model which has been running now for 4 years. It just isn't > >>>>>>> possible for a few people to migrate and test hundreds of boards. > >>>>>>> > >>>>>>> So, send a patch! > >>>>>> > >>>>>> OK, so with the intention of "need to light a fire", consider the fire > >>>>>> lit! But, I think v2 of this series needs to: > >>>>>> - Address the bug that's been noted of you checking on "DM_BLK" when > >>>>>> it's really just "BLK". > >>>>>> - Do a test build with BLK just being unconditional now. For example, > >>>>>> you're deleting the am335x_evm family but it builds fine with BLK > >>>>>> being enabled now. I even gave it a run time test via test.py and > >>>>>> we're fine. So, I think a new run where you see what fails to build > >>>>>> with BLK enabled by default now is in order to come up with a new > >>>>>> delete list. > >>>>>> > >>>>> > >>>>> When we were migrating toward GCC 6, we introduced a warning message > >>>>> that was displayed at build indicating older versions of GCC would be > >>>>> unsupported, and GCC 6 would become a requirement. The > >>>>> CONFIG_DM_I2C_COMPAT generates a build warning and suggests that it be > >>>>> removed. I would like to propose that in the future, when setting > >>>>> deadlines, we insert something into the build mechanism that generates > >>>>> a warning to tell people that something is going to happen. > >>>> > >>>> I agree, that sounds good. > >>>> > >>>> I am extremely unhappy by how Simon decided, unilaterally, some > >>>> arbitrary deadline, told pretty much no one about that deadline and then > >>>> put a knife on many peoples' throats by sending out this series which > >>>> removes boards that are actively used and maintained, demanding they be > >>>> converted right this instant. > >>> > >>> OK, lets step back for a moment. Part of the problem is that yes, we > >>> (I) never found a good way to make a big scary build warning happen. > >>> But, lets look at https://patchwork.ozlabs.org/patch/798309/ for a > >>> moment, which is when we set this deadline, and we had a good bit of > >>> discussion about related issues to make it happen. > >>> > >>> I also know that around the v2018.05 release I said, in public, but no I > >>> can't find a link right this moment, that we were pushing off a little > >>> bit on dropping _everything_ right then as there was basically some > >>> fairly important / widely used USB stuff that hadn't been converted yet > >>> (which has since been, I think, otherwise am335x_evm & co wouldn't have > >>> been happy?). I know I did since I can see in the archives a number of > >>> series where maintainers did a bunch of changes to various platforms / > >>> SoCs to turn on BLK right then. > >>> > >>> So, no, I don't want to drop a bunch of platforms _right_now_. But we > >>> really need to see what doesn't link anymore with BLK forced on, and > >>> plan from there. > >> > >> I remember the discussion, but it seems rather arbitrary for one > >> person to unilaterally start deleting boards. I think a more > >> appropriate approach would be to start a dialog instead of deleting > >> boards and then giving people a fairly short notice to respond - > >> especially this close to the US Thanksgiving holiday, several > >> religious holidays and New Years. Many people have planed time off > >> and/or end-of-year deadlines to hit without getting an abrupt suprise. > > > > ACK > > > I fully agree with Marek and Adam, but I have also some other technical > points related to i.MX6. > > I agree to move to new and better code, but this should not drop > important features that are appreciated by customers. Up now, U-Boot as > project was pretty conservative, trying t osupport as far as it is > possible even older architectures (MPC 88x, for example). > > On i.MX6, a feature is to have a single U-Boot binary (SPL + U-Boot) > running for more variants (Quad / Dual / Solo) of the SOC. This is done > with run time detection in code (SPL) - macros are provide to make the > work easy (it is, currently). There are plenty of boards doing this (all > listed by Simon for removal). This is common if the board has a SOM, and > of course the SOM is sold in different variants with different prices. > > If I understand well, moving to CONFIG_BLK means enabling CONFIG_DM_MMC > and this requires to set a DTS. But a DT is compiled by DTC, that means > we have a DT for each variant of the SOC. This forbids to have a single > binary and we need different binaries, one for each variant. We lose an > important feature, at least for some boards. Agree that having DT is > nice, but this should not drop what customer are asking. > > I know there are some improvement in TI code to get the root node in DT > and then load from it. Anyway, specially for i.MX6 solo, we are quite > running out of space in SRAM, mainly due to other required features. And > having multiple DTB with CONFIG_MULTI_DTB_FIT seems to work just if we > have no SPL. > > So first, it looks like that the issue is not so trivial as it was, and > second a technical solution must be searched for that. Yes, this is a useful feature on i.MX lines and we need to figure out how to keep it. 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?
On Tue, Nov 20, 2018 at 02:29:12PM +0000, Ian Campbell wrote: > (massively trimmed cc list, leaving the current sunxi custodians and > Hans who is a fellow emeritus custodian) > > On Mon, 2018-11-19 at 14:58 -0700, Simon Glass wrote: > > 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? I suspect a script went a bit overzealous somewhere, thanks!
Hi Tom, On 20/11/18 15:55, Tom Rini wrote: > On Tue, Nov 20, 2018 at 12:00:13PM +0100, Stefano Babic wrote: >> Hi, >> >> On 19/11/18 23:06, Marek Vasut wrote: >>> On 11/19/2018 11:02 PM, Adam Ford wrote: >>>> On Mon, Nov 19, 2018 at 3:54 PM Tom Rini <trini@konsulko.com> wrote: >>>>> >>>>> On Mon, Nov 19, 2018 at 10:32:01PM +0100, Marek Vasut wrote: >>>>>> On 11/19/2018 08:45 PM, Adam Ford wrote: >>>>>>> On Mon, Nov 19, 2018 at 12:36 PM Tom Rini <trini@konsulko.com> wrote: >>>>>>>> >>>>>>>> On Mon, Nov 19, 2018 at 10:54 AM Simon Glass <sjg@chromium.org> wrote: >>>>>>>>> >>>>>>>>> All boards should now be migrated to use CONFIG_BLK. This series removes >>>>>>>>> those with build problems using this option. >>>>>>>>> >>>>>>>>> If maintainers want to keep these boards in they should send a patch in >>>>>>>>> the next week or two. Otherwise the board will be removed in the next >>>>>>>>> release, and will need to be added and re-reviewed later. >>>>>>>>> >>>>>>>>> The goal is to have all boards use driver model. But so far, we do allow >>>>>>>>> CONFIG_DM to not be defined. >>>>>>>>> >>>>>>>>> PLEASE NOTE: This is not an easy process. It is possible that your board >>>>>>>>> does work, or works with only minor changes. Please try to understand that >>>>>>>>> the removal of a board is not done because people don't like your board. >>>>>>>>> In fact the board might have been the first one I used when trying out >>>>>>>>> U-Boot! It's just that we expect maintainers to keep up with the migration >>>>>>>>> to driver model which has been running now for 4 years. It just isn't >>>>>>>>> possible for a few people to migrate and test hundreds of boards. >>>>>>>>> >>>>>>>>> So, send a patch! >>>>>>>> >>>>>>>> OK, so with the intention of "need to light a fire", consider the fire >>>>>>>> lit! But, I think v2 of this series needs to: >>>>>>>> - Address the bug that's been noted of you checking on "DM_BLK" when >>>>>>>> it's really just "BLK". >>>>>>>> - Do a test build with BLK just being unconditional now. For example, >>>>>>>> you're deleting the am335x_evm family but it builds fine with BLK >>>>>>>> being enabled now. I even gave it a run time test via test.py and >>>>>>>> we're fine. So, I think a new run where you see what fails to build >>>>>>>> with BLK enabled by default now is in order to come up with a new >>>>>>>> delete list. >>>>>>>> >>>>>>> >>>>>>> When we were migrating toward GCC 6, we introduced a warning message >>>>>>> that was displayed at build indicating older versions of GCC would be >>>>>>> unsupported, and GCC 6 would become a requirement. The >>>>>>> CONFIG_DM_I2C_COMPAT generates a build warning and suggests that it be >>>>>>> removed. I would like to propose that in the future, when setting >>>>>>> deadlines, we insert something into the build mechanism that generates >>>>>>> a warning to tell people that something is going to happen. >>>>>> >>>>>> I agree, that sounds good. >>>>>> >>>>>> I am extremely unhappy by how Simon decided, unilaterally, some >>>>>> arbitrary deadline, told pretty much no one about that deadline and then >>>>>> put a knife on many peoples' throats by sending out this series which >>>>>> removes boards that are actively used and maintained, demanding they be >>>>>> converted right this instant. >>>>> >>>>> OK, lets step back for a moment. Part of the problem is that yes, we >>>>> (I) never found a good way to make a big scary build warning happen. >>>>> But, lets look at https://patchwork.ozlabs.org/patch/798309/ for a >>>>> moment, which is when we set this deadline, and we had a good bit of >>>>> discussion about related issues to make it happen. >>>>> >>>>> I also know that around the v2018.05 release I said, in public, but no I >>>>> can't find a link right this moment, that we were pushing off a little >>>>> bit on dropping _everything_ right then as there was basically some >>>>> fairly important / widely used USB stuff that hadn't been converted yet >>>>> (which has since been, I think, otherwise am335x_evm & co wouldn't have >>>>> been happy?). I know I did since I can see in the archives a number of >>>>> series where maintainers did a bunch of changes to various platforms / >>>>> SoCs to turn on BLK right then. >>>>> >>>>> So, no, I don't want to drop a bunch of platforms _right_now_. But we >>>>> really need to see what doesn't link anymore with BLK forced on, and >>>>> plan from there. >>>> >>>> I remember the discussion, but it seems rather arbitrary for one >>>> person to unilaterally start deleting boards. I think a more >>>> appropriate approach would be to start a dialog instead of deleting >>>> boards and then giving people a fairly short notice to respond - >>>> especially this close to the US Thanksgiving holiday, several >>>> religious holidays and New Years. Many people have planed time off >>>> and/or end-of-year deadlines to hit without getting an abrupt suprise. >>> >>> ACK >> >> >> I fully agree with Marek and Adam, but I have also some other technical >> points related to i.MX6. >> >> I agree to move to new and better code, but this should not drop >> important features that are appreciated by customers. Up now, U-Boot as >> project was pretty conservative, trying t osupport as far as it is >> possible even older architectures (MPC 88x, for example). >> >> On i.MX6, a feature is to have a single U-Boot binary (SPL + U-Boot) >> running for more variants (Quad / Dual / Solo) of the SOC. This is done >> with run time detection in code (SPL) - macros are provide to make the >> work easy (it is, currently). There are plenty of boards doing this (all >> listed by Simon for removal). This is common if the board has a SOM, and >> of course the SOM is sold in different variants with different prices. >> >> If I understand well, moving to CONFIG_BLK means enabling CONFIG_DM_MMC >> and this requires to set a DTS. But a DT is compiled by DTC, that means >> we have a DT for each variant of the SOC. This forbids to have a single >> binary and we need different binaries, one for each variant. We lose an >> important feature, at least for some boards. Agree that having DT is >> nice, but this should not drop what customer are asking. >> >> I know there are some improvement in TI code to get the root node in DT >> and then load from it. Anyway, specially for i.MX6 solo, we are quite >> running out of space in SRAM, mainly due to other required features. And >> having multiple DTB with CONFIG_MULTI_DTB_FIT seems to work just if we >> have no SPL. >> >> So first, it looks like that the issue is not so trivial as it was, and >> second a technical solution must be searched for that. > > Yes, this is a useful feature on i.MX lines and we need to figure out > how to keep it. Right, fully agree. > Perhaps we'll need some combination of > CONFIG_SPL_FIT_LOAD (and board_fit_config_name_match) along with perhaps > introducing a TPL to i.MX where we can get away with doing whatever we > need to do, to init DRAM and have enough space to put SPL and U-Boot? I am just figuring out how we can do. One other aspect introducing another stage as TPL could be the increased boot time, even if I guess it is not much. However, there are some applications in automotive that are very "sensible" to any increment in boot time. Regards, Stefano
On Tue, Nov 20, 2018 at 05:27:03PM +0100, Stefano Babic wrote: > Hi Tom, > > On 20/11/18 15:55, Tom Rini wrote: > > On Tue, Nov 20, 2018 at 12:00:13PM +0100, Stefano Babic wrote: > >> Hi, > >> > >> On 19/11/18 23:06, Marek Vasut wrote: > >>> On 11/19/2018 11:02 PM, Adam Ford wrote: > >>>> On Mon, Nov 19, 2018 at 3:54 PM Tom Rini <trini@konsulko.com> wrote: > >>>>> > >>>>> On Mon, Nov 19, 2018 at 10:32:01PM +0100, Marek Vasut wrote: > >>>>>> On 11/19/2018 08:45 PM, Adam Ford wrote: > >>>>>>> On Mon, Nov 19, 2018 at 12:36 PM Tom Rini <trini@konsulko.com> wrote: > >>>>>>>> > >>>>>>>> On Mon, Nov 19, 2018 at 10:54 AM Simon Glass <sjg@chromium.org> wrote: > >>>>>>>>> > >>>>>>>>> All boards should now be migrated to use CONFIG_BLK. This series removes > >>>>>>>>> those with build problems using this option. > >>>>>>>>> > >>>>>>>>> If maintainers want to keep these boards in they should send a patch in > >>>>>>>>> the next week or two. Otherwise the board will be removed in the next > >>>>>>>>> release, and will need to be added and re-reviewed later. > >>>>>>>>> > >>>>>>>>> The goal is to have all boards use driver model. But so far, we do allow > >>>>>>>>> CONFIG_DM to not be defined. > >>>>>>>>> > >>>>>>>>> PLEASE NOTE: This is not an easy process. It is possible that your board > >>>>>>>>> does work, or works with only minor changes. Please try to understand that > >>>>>>>>> the removal of a board is not done because people don't like your board. > >>>>>>>>> In fact the board might have been the first one I used when trying out > >>>>>>>>> U-Boot! It's just that we expect maintainers to keep up with the migration > >>>>>>>>> to driver model which has been running now for 4 years. It just isn't > >>>>>>>>> possible for a few people to migrate and test hundreds of boards. > >>>>>>>>> > >>>>>>>>> So, send a patch! > >>>>>>>> > >>>>>>>> OK, so with the intention of "need to light a fire", consider the fire > >>>>>>>> lit! But, I think v2 of this series needs to: > >>>>>>>> - Address the bug that's been noted of you checking on "DM_BLK" when > >>>>>>>> it's really just "BLK". > >>>>>>>> - Do a test build with BLK just being unconditional now. For example, > >>>>>>>> you're deleting the am335x_evm family but it builds fine with BLK > >>>>>>>> being enabled now. I even gave it a run time test via test.py and > >>>>>>>> we're fine. So, I think a new run where you see what fails to build > >>>>>>>> with BLK enabled by default now is in order to come up with a new > >>>>>>>> delete list. > >>>>>>>> > >>>>>>> > >>>>>>> When we were migrating toward GCC 6, we introduced a warning message > >>>>>>> that was displayed at build indicating older versions of GCC would be > >>>>>>> unsupported, and GCC 6 would become a requirement. The > >>>>>>> CONFIG_DM_I2C_COMPAT generates a build warning and suggests that it be > >>>>>>> removed. I would like to propose that in the future, when setting > >>>>>>> deadlines, we insert something into the build mechanism that generates > >>>>>>> a warning to tell people that something is going to happen. > >>>>>> > >>>>>> I agree, that sounds good. > >>>>>> > >>>>>> I am extremely unhappy by how Simon decided, unilaterally, some > >>>>>> arbitrary deadline, told pretty much no one about that deadline and then > >>>>>> put a knife on many peoples' throats by sending out this series which > >>>>>> removes boards that are actively used and maintained, demanding they be > >>>>>> converted right this instant. > >>>>> > >>>>> OK, lets step back for a moment. Part of the problem is that yes, we > >>>>> (I) never found a good way to make a big scary build warning happen. > >>>>> But, lets look at https://patchwork.ozlabs.org/patch/798309/ for a > >>>>> moment, which is when we set this deadline, and we had a good bit of > >>>>> discussion about related issues to make it happen. > >>>>> > >>>>> I also know that around the v2018.05 release I said, in public, but no I > >>>>> can't find a link right this moment, that we were pushing off a little > >>>>> bit on dropping _everything_ right then as there was basically some > >>>>> fairly important / widely used USB stuff that hadn't been converted yet > >>>>> (which has since been, I think, otherwise am335x_evm & co wouldn't have > >>>>> been happy?). I know I did since I can see in the archives a number of > >>>>> series where maintainers did a bunch of changes to various platforms / > >>>>> SoCs to turn on BLK right then. > >>>>> > >>>>> So, no, I don't want to drop a bunch of platforms _right_now_. But we > >>>>> really need to see what doesn't link anymore with BLK forced on, and > >>>>> plan from there. > >>>> > >>>> I remember the discussion, but it seems rather arbitrary for one > >>>> person to unilaterally start deleting boards. I think a more > >>>> appropriate approach would be to start a dialog instead of deleting > >>>> boards and then giving people a fairly short notice to respond - > >>>> especially this close to the US Thanksgiving holiday, several > >>>> religious holidays and New Years. Many people have planed time off > >>>> and/or end-of-year deadlines to hit without getting an abrupt suprise. > >>> > >>> ACK > >> > >> > >> I fully agree with Marek and Adam, but I have also some other technical > >> points related to i.MX6. > >> > >> I agree to move to new and better code, but this should not drop > >> important features that are appreciated by customers. Up now, U-Boot as > >> project was pretty conservative, trying t osupport as far as it is > >> possible even older architectures (MPC 88x, for example). > >> > >> On i.MX6, a feature is to have a single U-Boot binary (SPL + U-Boot) > >> running for more variants (Quad / Dual / Solo) of the SOC. This is done > >> with run time detection in code (SPL) - macros are provide to make the > >> work easy (it is, currently). There are plenty of boards doing this (all > >> listed by Simon for removal). This is common if the board has a SOM, and > >> of course the SOM is sold in different variants with different prices. > >> > >> If I understand well, moving to CONFIG_BLK means enabling CONFIG_DM_MMC > >> and this requires to set a DTS. But a DT is compiled by DTC, that means > >> we have a DT for each variant of the SOC. This forbids to have a single > >> binary and we need different binaries, one for each variant. We lose an > >> important feature, at least for some boards. Agree that having DT is > >> nice, but this should not drop what customer are asking. > >> > >> I know there are some improvement in TI code to get the root node in DT > >> and then load from it. Anyway, specially for i.MX6 solo, we are quite > >> running out of space in SRAM, mainly due to other required features. And > >> having multiple DTB with CONFIG_MULTI_DTB_FIT seems to work just if we > >> have no SPL. > >> > >> So first, it looks like that the issue is not so trivial as it was, and > >> second a technical solution must be searched for that. > > > > Yes, this is a useful feature on i.MX lines and we need to figure out > > how to keep it. > > Right, fully agree. > > > Perhaps we'll need some combination of > > CONFIG_SPL_FIT_LOAD (and board_fit_config_name_match) along with perhaps > > introducing a TPL to i.MX where we can get away with doing whatever we > > need to do, to init DRAM and have enough space to put SPL and U-Boot? > > I am just figuring out how we can do. One other aspect introducing > another stage as TPL could be the increased boot time, even if I guess > it is not much. However, there are some applications in automotive that > are very "sensible" to any increment in boot time. I would hope that it's no more a change in measurable boot time than anything else that changes in the code base, but that might also be the point when it's time to tune the build into a single config (as I would _hope_ any run-time differences between board revs can be pushed back to OS time or at least full U-Boot rather than initial steps but DRAM config could complicate that).
Hi again, On Mon, 19 Nov 2018 at 14:58, Simon Glass <sjg@chromium.org> wrote: > > Hi, > > On Mon, 19 Nov 2018 at 14:54, Tom Rini <trini@konsulko.com> wrote: > > > > On Mon, Nov 19, 2018 at 10:32:01PM +0100, Marek Vasut wrote: > > > On 11/19/2018 08:45 PM, Adam Ford wrote: > > > > On Mon, Nov 19, 2018 at 12:36 PM Tom Rini <trini@konsulko.com> wrote: > > > >> > > > >> On Mon, Nov 19, 2018 at 10:54 AM Simon Glass <sjg@chromium.org> wrote: > > > >>> > > > >>> All boards should now be migrated to use CONFIG_BLK. This series removes > > > >>> those with build problems using this option. > > > >>> > > > >>> If maintainers want to keep these boards in they should send a patch in > > > >>> the next week or two. Otherwise the board will be removed in the next > > > >>> release, and will need to be added and re-reviewed later. > > > >>> > > > >>> The goal is to have all boards use driver model. But so far, we do allow > > > >>> CONFIG_DM to not be defined. > > > >>> > > > >>> PLEASE NOTE: This is not an easy process. It is possible that your board > > > >>> does work, or works with only minor changes. Please try to understand that > > > >>> the removal of a board is not done because people don't like your board. > > > >>> In fact the board might have been the first one I used when trying out > > > >>> U-Boot! It's just that we expect maintainers to keep up with the migration > > > >>> to driver model which has been running now for 4 years. It just isn't > > > >>> possible for a few people to migrate and test hundreds of boards. > > > >>> > > > >>> So, send a patch! > > > >> > > > >> OK, so with the intention of "need to light a fire", consider the fire > > > >> lit! But, I think v2 of this series needs to: > > > >> - Address the bug that's been noted of you checking on "DM_BLK" when > > > >> it's really just "BLK". > > > >> - Do a test build with BLK just being unconditional now. For example, > > > >> you're deleting the am335x_evm family but it builds fine with BLK > > > >> being enabled now. I even gave it a run time test via test.py and > > > >> we're fine. So, I think a new run where you see what fails to build > > > >> with BLK enabled by default now is in order to come up with a new > > > >> delete list. > > > >> > > > > > > > > When we were migrating toward GCC 6, we introduced a warning message > > > > that was displayed at build indicating older versions of GCC would be > > > > unsupported, and GCC 6 would become a requirement. The > > > > CONFIG_DM_I2C_COMPAT generates a build warning and suggests that it be > > > > removed. I would like to propose that in the future, when setting > > > > deadlines, we insert something into the build mechanism that generates > > > > a warning to tell people that something is going to happen. > > > > > > I agree, that sounds good. > > > > > > I am extremely unhappy by how Simon decided, unilaterally, some > > > arbitrary deadline, told pretty much no one about that deadline and then > > > put a knife on many peoples' throats by sending out this series which > > > removes boards that are actively used and maintained, demanding they be > > > converted right this instant. > > > > OK, lets step back for a moment. Part of the problem is that yes, we > > (I) never found a good way to make a big scary build warning happen. > > But, lets look at https://patchwork.ozlabs.org/patch/798309/ for a > > moment, which is when we set this deadline, and we had a good bit of > > discussion about related issues to make it happen. > > > > I also know that around the v2018.05 release I said, in public, but no I > > can't find a link right this moment, that we were pushing off a little > > bit on dropping _everything_ right then as there was basically some > > fairly important / widely used USB stuff that hadn't been converted yet > > (which has since been, I think, otherwise am335x_evm & co wouldn't have > > been happy?). I know I did since I can see in the archives a number of > > series where maintainers did a bunch of changes to various platforms / > > SoCs to turn on BLK right then. > > > > So, no, I don't want to drop a bunch of platforms _right_now_. But we > > really need to see what doesn't link anymore with BLK forced on, and > > plan from there. > > 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. 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. Regards, Simon
On Tue, Nov 20, 2018 at 09:43:04PM -0700, Simon Glass wrote: > Hi again, > > On Mon, 19 Nov 2018 at 14:58, Simon Glass <sjg@chromium.org> wrote: > > > > Hi, > > > > On Mon, 19 Nov 2018 at 14:54, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Mon, Nov 19, 2018 at 10:32:01PM +0100, Marek Vasut wrote: > > > > On 11/19/2018 08:45 PM, Adam Ford wrote: > > > > > On Mon, Nov 19, 2018 at 12:36 PM Tom Rini <trini@konsulko.com> wrote: > > > > >> > > > > >> On Mon, Nov 19, 2018 at 10:54 AM Simon Glass <sjg@chromium.org> wrote: > > > > >>> > > > > >>> All boards should now be migrated to use CONFIG_BLK. This series removes > > > > >>> those with build problems using this option. > > > > >>> > > > > >>> If maintainers want to keep these boards in they should send a patch in > > > > >>> the next week or two. Otherwise the board will be removed in the next > > > > >>> release, and will need to be added and re-reviewed later. > > > > >>> > > > > >>> The goal is to have all boards use driver model. But so far, we do allow > > > > >>> CONFIG_DM to not be defined. > > > > >>> > > > > >>> PLEASE NOTE: This is not an easy process. It is possible that your board > > > > >>> does work, or works with only minor changes. Please try to understand that > > > > >>> the removal of a board is not done because people don't like your board. > > > > >>> In fact the board might have been the first one I used when trying out > > > > >>> U-Boot! It's just that we expect maintainers to keep up with the migration > > > > >>> to driver model which has been running now for 4 years. It just isn't > > > > >>> possible for a few people to migrate and test hundreds of boards. > > > > >>> > > > > >>> So, send a patch! > > > > >> > > > > >> OK, so with the intention of "need to light a fire", consider the fire > > > > >> lit! But, I think v2 of this series needs to: > > > > >> - Address the bug that's been noted of you checking on "DM_BLK" when > > > > >> it's really just "BLK". > > > > >> - Do a test build with BLK just being unconditional now. For example, > > > > >> you're deleting the am335x_evm family but it builds fine with BLK > > > > >> being enabled now. I even gave it a run time test via test.py and > > > > >> we're fine. So, I think a new run where you see what fails to build > > > > >> with BLK enabled by default now is in order to come up with a new > > > > >> delete list. > > > > >> > > > > > > > > > > When we were migrating toward GCC 6, we introduced a warning message > > > > > that was displayed at build indicating older versions of GCC would be > > > > > unsupported, and GCC 6 would become a requirement. The > > > > > CONFIG_DM_I2C_COMPAT generates a build warning and suggests that it be > > > > > removed. I would like to propose that in the future, when setting > > > > > deadlines, we insert something into the build mechanism that generates > > > > > a warning to tell people that something is going to happen. > > > > > > > > I agree, that sounds good. > > > > > > > > I am extremely unhappy by how Simon decided, unilaterally, some > > > > arbitrary deadline, told pretty much no one about that deadline and then > > > > put a knife on many peoples' throats by sending out this series which > > > > removes boards that are actively used and maintained, demanding they be > > > > converted right this instant. > > > > > > OK, lets step back for a moment. Part of the problem is that yes, we > > > (I) never found a good way to make a big scary build warning happen. > > > But, lets look at https://patchwork.ozlabs.org/patch/798309/ for a > > > moment, which is when we set this deadline, and we had a good bit of > > > discussion about related issues to make it happen. > > > > > > I also know that around the v2018.05 release I said, in public, but no I > > > can't find a link right this moment, that we were pushing off a little > > > bit on dropping _everything_ right then as there was basically some > > > fairly important / widely used USB stuff that hadn't been converted yet > > > (which has since been, I think, otherwise am335x_evm & co wouldn't have > > > been happy?). I know I did since I can see in the archives a number of > > > series where maintainers did a bunch of changes to various platforms / > > > SoCs to turn on BLK right then. > > > > > > So, no, I don't want to drop a bunch of platforms _right_now_. But we > > > really need to see what doesn't link anymore with BLK forced on, and > > > plan from there. > > > > 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. > > 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. I think this is going the wrong way still. So I'll go and kick off a test set of builds where we make BLK be default y for DM and see what breaks. That will show us what subsystems / drivers haven't been converted yet and that in turn is what we need to deal with removing or converting. This isn't exactly a "board" issue but rather a driver issue and while there is some overlap I think aiming at boards is the wrong way.
On Tue, Nov 20, 2018 at 08:53:12AM -0500, Tom Rini wrote: > On Tue, Nov 20, 2018 at 02:45:24PM +0100, Marek Vasut wrote: > > On 11/20/2018 02:42 PM, Tom Rini wrote: > > > On Tue, Nov 20, 2018 at 02:40:43PM +0100, Marek Vasut wrote: > > >> On 11/20/2018 02:37 PM, Tom Rini wrote: > > >>> On Tue, Nov 20, 2018 at 01:42:15PM +0100, Soeren Moch wrote: > > >>>> > > >>>> > > >>>> 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. > > >>> > > >>>> 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. > > >> > > >> 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. > > > >> 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). 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.
On Mon, Nov 19, 2018 at 10:54 AM Simon Glass <sjg@chromium.org> wrote: > > All boards should now be migrated to use CONFIG_BLK. This series removes > those with build problems using this option. > > If maintainers want to keep these boards in they should send a patch in > the next week or two. Otherwise the board will be removed in the next > release, and will need to be added and re-reviewed later. > > The goal is to have all boards use driver model. But so far, we do allow > CONFIG_DM to not be defined. Hey everyone. Did we scare you perhaps a bit too much? Sorry. We're not going to be dropping boards quite just yet as we have a few drivers yet that need converting and that in turn is what's blocking some amount of easy mass conversion. That said, does your board set CONFIG_OF_CONTROL and related? If not, you do indeed have some work to go and do or the platform will be dropped. Not immediately but we have come far enough along in our conversions that as a general rule, you should be using DM in full U-Boot and figuring out how to use DM in SPL (and if there's some problem, speaking up so we can figure out a solution). Thanks all!
Hi Tom, On Wed, 21 Nov 2018 at 08:10, Tom Rini <trini@konsulko.com> wrote: > > On Tue, Nov 20, 2018 at 08:53:12AM -0500, Tom Rini wrote: > > On Tue, Nov 20, 2018 at 02:45:24PM +0100, Marek Vasut wrote: > > > On 11/20/2018 02:42 PM, Tom Rini wrote: > > > > On Tue, Nov 20, 2018 at 02:40:43PM +0100, Marek Vasut wrote: > > > >> On 11/20/2018 02:37 PM, Tom Rini wrote: > > > >>> On Tue, Nov 20, 2018 at 01:42:15PM +0100, Soeren Moch wrote: > > > >>>> > > > >>>> > > > >>>> 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. > > > >>> > > > >>>> 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. > > > >> > > > >> 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. > > > > > >> 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). > > 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. Regards, Simon
On Thu, Nov 22, 2018 at 01:50:34PM -0700, Simon Glass wrote: > Hi Tom, > > On Wed, 21 Nov 2018 at 08:10, Tom Rini <trini@konsulko.com> wrote: > > > > On Tue, Nov 20, 2018 at 08:53:12AM -0500, Tom Rini wrote: > > > On Tue, Nov 20, 2018 at 02:45:24PM +0100, Marek Vasut wrote: > > > > On 11/20/2018 02:42 PM, Tom Rini wrote: > > > > > On Tue, Nov 20, 2018 at 02:40:43PM +0100, Marek Vasut wrote: > > > > >> On 11/20/2018 02:37 PM, Tom Rini wrote: > > > > >>> On Tue, Nov 20, 2018 at 01:42:15PM +0100, Soeren Moch wrote: > > > > >>>> > > > > >>>> > > > > >>>> 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. > > > > >>> > > > > >>>> 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. > > > > >> > > > > >> 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. > > > > > > > >> 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). > > > > 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. 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 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 Soeren, On Tue, Nov 20, 2018 at 10:44 AM Soeren Moch <smoch@web.de> wrote: > 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. Regards, Fabio Estevam
Hi Tom, On Thu, 22 Nov 2018 at 16:31, Tom Rini <trini@konsulko.com> wrote: > > On Thu, Nov 22, 2018 at 01:50:34PM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Wed, 21 Nov 2018 at 08:10, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Tue, Nov 20, 2018 at 08:53:12AM -0500, Tom Rini wrote: > > > > On Tue, Nov 20, 2018 at 02:45:24PM +0100, Marek Vasut wrote: > > > > > On 11/20/2018 02:42 PM, Tom Rini wrote: > > > > > > On Tue, Nov 20, 2018 at 02:40:43PM +0100, Marek Vasut wrote: > > > > > >> On 11/20/2018 02:37 PM, Tom Rini wrote: > > > > > >>> On Tue, Nov 20, 2018 at 01:42:15PM +0100, Soeren Moch wrote: > > > > > >>>> > > > > > >>>> > > > > > >>>> 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. > > > > > >>> > > > > > >>>> 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. > > > > > >> > > > > > >> 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. > > > > > > > > > >> 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). > > > > > > 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. > > 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. > > > 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. 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? Regards, Simon
Hi Fabio, On 23.11.18 01:31, Fabio Estevam wrote: > Hi Soeren, > > On Tue, Nov 20, 2018 at 10:44 AM Soeren Moch <smoch@web.de> wrote: > >> 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. Unfortunately, there are no imx6q (or 6d, 6dl) boards in this list. I guess (have not investigated in detail) this is due to missing SATA support under CONFIG_BLK for 6qdl. Maybe other additional problems. So I'm afraid I cannot do this conversion on my own. However, I'm happy to test anything what becomes available. At least there is only a imx6q variant of tbs2910, so no additional worries about different dtbs or SPL. Regards, Soeren
On Fri, Nov 23, 2018 at 05:04:46AM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 22 Nov 2018 at 16:31, Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Nov 22, 2018 at 01:50:34PM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Wed, 21 Nov 2018 at 08:10, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Tue, Nov 20, 2018 at 08:53:12AM -0500, Tom Rini wrote: > > > > > On Tue, Nov 20, 2018 at 02:45:24PM +0100, Marek Vasut wrote: > > > > > > On 11/20/2018 02:42 PM, Tom Rini wrote: > > > > > > > On Tue, Nov 20, 2018 at 02:40:43PM +0100, Marek Vasut wrote: > > > > > > >> On 11/20/2018 02:37 PM, Tom Rini wrote: > > > > > > >>> On Tue, Nov 20, 2018 at 01:42:15PM +0100, Soeren Moch wrote: > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> 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. > > > > > > >>> > > > > > > >>>> 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. > > > > > > >> > > > > > > >> 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. > > > > > > > > > > > >> 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). > > > > > > > > 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. > > > > 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. > > > > > > 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. > > 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.
On Sat, Nov 24, 2018 at 12:41:53PM -0700, Simon Glass wrote: > Hi Tom, > > On Fri, 23 Nov 2018 at 12:38, Tom Rini <trini@konsulko.com> wrote: > > > > On Fri, Nov 23, 2018 at 05:04:46AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 22 Nov 2018 at 16:31, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Thu, Nov 22, 2018 at 01:50:34PM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Wed, 21 Nov 2018 at 08:10, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Tue, Nov 20, 2018 at 08:53:12AM -0500, Tom Rini wrote: > > > > > > > On Tue, Nov 20, 2018 at 02:45:24PM +0100, Marek Vasut wrote: > > > > > > > > On 11/20/2018 02:42 PM, Tom Rini wrote: > > > > > > > > > On Tue, Nov 20, 2018 at 02:40:43PM +0100, Marek Vasut wrote: > > > > > > > > >> On 11/20/2018 02:37 PM, Tom Rini wrote: > > > > > > > > >>> On Tue, Nov 20, 2018 at 01:42:15PM +0100, Soeren Moch wrote: > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>> 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. > > > > > > > > >>> > > > > > > > > >>>> 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. > > > > > > > > >> > > > > > > > > >> 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. > > > > > > > > > > > > > > > >> 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). > > > > > > > > > > > > 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. > > > > > > > > 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. > > > > > > > > > > > > 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. > > > > > > 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. > > 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. > 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).
Hi Tom. On Sun, 25 Nov 2018 at 18:12, Tom Rini <trini@konsulko.com> wrote: > > On Sat, Nov 24, 2018 at 12:41:53PM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Fri, 23 Nov 2018 at 12:38, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Fri, Nov 23, 2018 at 05:04:46AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 22 Nov 2018 at 16:31, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Thu, Nov 22, 2018 at 01:50:34PM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Wed, 21 Nov 2018 at 08:10, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > On Tue, Nov 20, 2018 at 08:53:12AM -0500, Tom Rini wrote: > > > > > > > > On Tue, Nov 20, 2018 at 02:45:24PM +0100, Marek Vasut wrote: > > > > > > > > > On 11/20/2018 02:42 PM, Tom Rini wrote: > > > > > > > > > > On Tue, Nov 20, 2018 at 02:40:43PM +0100, Marek Vasut wrote: > > > > > > > > > >> On 11/20/2018 02:37 PM, Tom Rini wrote: > > > > > > > > > >>> On Tue, Nov 20, 2018 at 01:42:15PM +0100, Soeren Moch wrote: > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > > >>>> 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. > > > > > > > > > >>> > > > > > > > > > >>>> 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. > > > > > > > > > >> > > > > > > > > > >> 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. > > > > > > > > > > > > > > > > > >> 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). > > > > > > > > > > > > > > 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. > > > > > > > > > > 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. > > > > > > > > > > > > > > > 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. > > > > > > > > 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. > > > > 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. Yes I think the alarms are ringing :-) The body count is definitely too high right now. > > > 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). Yes that seems quite close. I'll take a look at some other subsystems that might be close, or need conversion. Perhaps we should add warnings for most/all of them. Regards, Simon