| Message ID | pull-1386643347-596413 |
|---|---|
| State | New |
| Headers | show |
On Mon, Dec 09, 2013 at 06:42:27PM -0800, Tony Lindgren wrote: > We can now finally make mach-omap2 to boot with device tree only and get > rid of over 20k lines of platform init code that way. > > Most basic devices already work using device tree based initialization > and the remaining devices can be initialized using platform data > with pdata-quirks.c. > > So for most missing boards it's just a question of adding a .dts file > that should be fairly similar to one of the existing .dts files as > we've tried to cover all basic omap3 board types. > > For people getting started updating their board files to for device > tree, there are some basic instructions in commit 8dc8b3ddf5d7 > (ARM: OMAP2+: Remove legacy omap3 board-*.c files and make mach-omap2 > DT only for booting). > > Please also note that there are also some related fixes making their way > into the mainline kernel that are needed for some use cases: > > PM off-idle for omap3 and wake-up events need the following two patches: While this is good, what seems to be happening is a complete switch from one method of booting to a different method of booting with no compatibility inbetween. We're going from only supporting the ATAG booting protocol for these platforms in v3.12 to only supporting the DT booting protocol in v3.13. There's no forward or backwards compatibility - it's one or the other. This is bad: this is the kind of "flag day" change which Linus hates - and I hate it because it means I need to update my build test system at the same time that arm-soc merges this stuff. This is utterly crap - it's crap not only from the point of view of the user perspective, but also from the development methodology point of view.
* Russell King - ARM Linux <linux@arm.linux.org.uk> [131210 06:37]: > On Mon, Dec 09, 2013 at 06:42:27PM -0800, Tony Lindgren wrote: > > We can now finally make mach-omap2 to boot with device tree only and get > > rid of over 20k lines of platform init code that way. > > > > Most basic devices already work using device tree based initialization > > and the remaining devices can be initialized using platform data > > with pdata-quirks.c. > > > > So for most missing boards it's just a question of adding a .dts file > > that should be fairly similar to one of the existing .dts files as > > we've tried to cover all basic omap3 board types. > > > > For people getting started updating their board files to for device > > tree, there are some basic instructions in commit 8dc8b3ddf5d7 > > (ARM: OMAP2+: Remove legacy omap3 board-*.c files and make mach-omap2 > > DT only for booting). > > > > Please also note that there are also some related fixes making their way > > into the mainline kernel that are needed for some use cases: > > > > PM off-idle for omap3 and wake-up events need the following two patches: > > While this is good, what seems to be happening is a complete switch > from one method of booting to a different method of booting with no > compatibility inbetween. We're going from only supporting the ATAG > booting protocol for these platforms in v3.12 to only supporting the > DT booting protocol in v3.13. There's no forward or backwards > compatibility - it's one or the other. Hmm hey this is for v3.14, not for v3.13. The reason why I've been sending fixes all over the place is to have them out of the way for v3.13 so we have v3.13 work reasonably the same way with both legacy booting and device tree based booting. Of course some .dts files will not be there for v3.13 though. > This is bad: this is the kind of "flag day" change which Linus hates - > and I hate it because it means I need to update my build test system > at the same time that arm-soc merges this stuff. Unfortunately there's no way around that unless we carry the legacy booting setup for longer. We can certainly postpone the flip over if if there's a real neeed to do it. But if the issue is just building an appended DTB image, I'd rather just get done with it as that problem we're always going to have no matter how much we delay the flip over. > This is utterly crap - it's crap not only from the point of view of the > user perspective, but also from the development methodology point of > view. The crappy part here is the fact that we need to build the kernel with appended DTB. Maybe there's something more we can do to make it easier. Regards, Tony
On Tue, Dec 10, 2013 at 08:01:44AM -0800, Tony Lindgren wrote: > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131210 06:37]: > > On Mon, Dec 09, 2013 at 06:42:27PM -0800, Tony Lindgren wrote: > > > We can now finally make mach-omap2 to boot with device tree only and get > > > rid of over 20k lines of platform init code that way. > > > > > > Most basic devices already work using device tree based initialization > > > and the remaining devices can be initialized using platform data > > > with pdata-quirks.c. > > > > > > So for most missing boards it's just a question of adding a .dts file > > > that should be fairly similar to one of the existing .dts files as > > > we've tried to cover all basic omap3 board types. > > > > > > For people getting started updating their board files to for device > > > tree, there are some basic instructions in commit 8dc8b3ddf5d7 > > > (ARM: OMAP2+: Remove legacy omap3 board-*.c files and make mach-omap2 > > > DT only for booting). > > > > > > Please also note that there are also some related fixes making their way > > > into the mainline kernel that are needed for some use cases: > > > > > > PM off-idle for omap3 and wake-up events need the following two patches: > > > > While this is good, what seems to be happening is a complete switch > > from one method of booting to a different method of booting with no > > compatibility inbetween. We're going from only supporting the ATAG > > booting protocol for these platforms in v3.12 to only supporting the > > DT booting protocol in v3.13. There's no forward or backwards > > compatibility - it's one or the other. > > Hmm hey this is for v3.14, not for v3.13. Yes, I meant 3.14. > > This is bad: this is the kind of "flag day" change which Linus hates - > > and I hate it because it means I need to update my build test system > > at the same time that arm-soc merges this stuff. > > Unfortunately there's no way around that unless we carry the legacy > booting setup for longer. We can certainly postpone the flip over if > if there's a real neeed to do it. > > But if the issue is just building an appended DTB image, I'd rather just > get done with it as that problem we're always going to have no matter > how much we delay the flip over. Right, so I should just turn off building OMAP3 for the remainder of this cycle. What's the fscking point me running a build system, because if I switch it now, OMAP3 breaks. If I don't switch it now and your pull request is merged, it breaks at that point. This is utterly insane.
* Russell King - ARM Linux <linux@arm.linux.org.uk> [131210 08:08]: > On Tue, Dec 10, 2013 at 08:01:44AM -0800, Tony Lindgren wrote: > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131210 06:37]: > > > On Mon, Dec 09, 2013 at 06:42:27PM -0800, Tony Lindgren wrote: > > > > We can now finally make mach-omap2 to boot with device tree only and get > > > > rid of over 20k lines of platform init code that way. > > > > > > > > Most basic devices already work using device tree based initialization > > > > and the remaining devices can be initialized using platform data > > > > with pdata-quirks.c. > > > > > > > > So for most missing boards it's just a question of adding a .dts file > > > > that should be fairly similar to one of the existing .dts files as > > > > we've tried to cover all basic omap3 board types. > > > > > > > > For people getting started updating their board files to for device > > > > tree, there are some basic instructions in commit 8dc8b3ddf5d7 > > > > (ARM: OMAP2+: Remove legacy omap3 board-*.c files and make mach-omap2 > > > > DT only for booting). > > > > > > > > Please also note that there are also some related fixes making their way > > > > into the mainline kernel that are needed for some use cases: > > > > > > > > PM off-idle for omap3 and wake-up events need the following two patches: > > > > > > While this is good, what seems to be happening is a complete switch > > > from one method of booting to a different method of booting with no > > > compatibility inbetween. We're going from only supporting the ATAG > > > booting protocol for these platforms in v3.12 to only supporting the > > > DT booting protocol in v3.13. There's no forward or backwards > > > compatibility - it's one or the other. > > > > Hmm hey this is for v3.14, not for v3.13. > > Yes, I meant 3.14. > > > > This is bad: this is the kind of "flag day" change which Linus hates - > > > and I hate it because it means I need to update my build test system > > > at the same time that arm-soc merges this stuff. > > > > Unfortunately there's no way around that unless we carry the legacy > > booting setup for longer. We can certainly postpone the flip over if > > if there's a real neeed to do it. > > > > But if the issue is just building an appended DTB image, I'd rather just > > get done with it as that problem we're always going to have no matter > > how much we delay the flip over. > > Right, so I should just turn off building OMAP3 for the remainder of this > cycle. > > What's the fscking point me running a build system, because if I switch > it now, OMAP3 breaks. If I don't switch it now and your pull request is > merged, it breaks at that point. Fair enough, I hear you. > This is utterly insane. Well let's do this. Let's merge the parts that add stuff now, then wait a week (or longer as needed) so you have both ways working with linux next for a while. Does that sounds reasonable to you? Regards, Tony
On Tuesday 10 December 2013, Tony Lindgren wrote: > The crappy part here is the fact that we need to build the kernel with > appended DTB. Maybe there's something more we can do to make it easier. > You are aware of the impedence matcher project [1], right? Arnd [1] https://github.com/zonque/pxa-impedance-matcher
* Arnd Bergmann <arnd@arndb.de> [131210 10:38]: > On Tuesday 10 December 2013, Tony Lindgren wrote: > > The crappy part here is the fact that we need to build the kernel with > > appended DTB. Maybe there's something more we can do to make it easier. > > > > You are aware of the impedence matcher project [1], right? Oh OK cool :) AFAIK the only omaps we're currently supporting in the mainline tree where the bootloader cannot be updated easily are the n9* that require a signed bootloader. But I think those already have some kind of 3rd stage bootloaders available for them. Regards, Tony > [1] https://github.com/zonque/pxa-impedance-matcher
On Mon, 9 Dec 2013, Tony Lindgren wrote: > The following changes since commit f2e2c9d9b4087b74eb9e00d8dfac148354cb0b71: > > ARM: dts: Fix booting for secure omaps (2013-12-06 15:30:43 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.14/omap3-board-removal-signed > > for you to fetch changes up to 736e812636ea72be444b85fa7e92554967459069: > > ARM: OMAP2+: Remove unused platform init code and headers (2013-12-08 14:15:46 -0800) The description in Tony's pull request below alludes to what regressions will occur when this is pulled. But just to state it in terms of what happened on the local testbed here when I tried it: - CM-T3517 booting will break since there's no .dts file for it. Are there other boards that will be affected here too? - 2430SDP NFS root will hang during boot, presumably due to the lack of the smc91x patch that is mentioned below - Dynamic idle PM tests will fail, due to the lack of the first two patches that Tony mentioned. (This is also a problem now for 37xxevm in v3.13-rc.) - The N800 isn't booting here with a concatenated uImage+dtb - but maybe I'm doing something wrong with this one. Best if the pull request were to explicitly state the known regressions with this series, in terms of specific boards and configurations. That way, people will know what to expect. > ---------------------------------------------------------------- > We can now finally make mach-omap2 to boot with device tree only and get > rid of over 20k lines of platform init code that way. > > Most basic devices already work using device tree based initialization > and the remaining devices can be initialized using platform data > with pdata-quirks.c. > > So for most missing boards it's just a question of adding a .dts file > that should be fairly similar to one of the existing .dts files as > we've tried to cover all basic omap3 board types. > > For people getting started updating their board files to for device > tree, there are some basic instructions in commit 8dc8b3ddf5d7 > (ARM: OMAP2+: Remove legacy omap3 board-*.c files and make mach-omap2 > DT only for booting). > > Please also note that there are also some related fixes making their way > into the mainline kernel that are needed for some use cases: > > PM off-idle for omap3 and wake-up events need the following two patches: > > [PATCH] of/platform: Fix no irq domain found errors when populating interrupts > http://lkml.org/lkml/2013/11/22/520 > > [PATCH] ARM: dts: Fix omap serial wake-up when booted with device tree > http://www.spinics.net/lists/devicetree/msg13374.html > > EMAC Ethernet on am3517 boards needs: > > [PATCH] net: davinci_emac: Fix platform data handling and make usable for am3517 > http://patchwork.ozlabs.org/patch/296351/ > > Ethernet for boards using smc91x needs: > > [PATCH v2] net: smc91x: Fix device tree based configuration so it's usable > http://www.spinics.net/lists/netdev/msg258913.html > (snip) - Paul
* Paul Walmsley <paul@pwsan.com> [131210 10:47]: > On Mon, 9 Dec 2013, Tony Lindgren wrote: > > > The following changes since commit f2e2c9d9b4087b74eb9e00d8dfac148354cb0b71: > > > > ARM: dts: Fix booting for secure omaps (2013-12-06 15:30:43 -0800) > > > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.14/omap3-board-removal-signed > > > > for you to fetch changes up to 736e812636ea72be444b85fa7e92554967459069: > > > > ARM: OMAP2+: Remove unused platform init code and headers (2013-12-08 14:15:46 -0800) > > The description in Tony's pull request below alludes to what regressions > will occur when this is pulled. But just to state it in terms of what > happened on the local testbed here when I tried it: > > - CM-T3517 booting will break since there's no .dts file for it. Are > there other boards that will be affected here too? Yeah the cm-t3770 is on my todo list, but I've left it last as it's my home router and has been behaving quite nicely. That should then cover: SBC-T3530 http://compulab.co.il/products/sbcs/sbc-t3530/ SBC-T3517 http://compulab.co.il/products/sbcs/sbc-t3517/ SBC-T3730 http://compulab.co.il/products/sbcs/sbc-t3730/ They all seem to have the same baseboard, and the CPU module is different. So getting the 3530 and 3517 variants working should be trivial. I don't have 3530 or 3517 variants, so somebody else will need to do those two. And Nishant just posted a .dts file for the 3517 craneboard. > - 2430SDP NFS root will hang during boot, presumably due to the lack > of the smc91x patch that is mentioned below Yes that's correct, hopefully we'll have that in v3.13. > - Dynamic idle PM tests will fail, due to the lack of the first two > patches that Tony mentioned. (This is also a problem now for > 37xxevm in v3.13-rc.) Yes that's something that should be fixes for v3.13 as well. > - The N800 isn't booting here with a concatenated uImage+dtb - but > maybe I'm doing something wrong with this one. Hmm n800 works for me here for sure, I can n-uple check today. > Best if the pull request were to explicitly state the known > regressions with this series, in terms of specific boards and > configurations. That way, people will know what to expect. Well ideally we would have no regressions when doing this, but I've been chasing people and bugs for few years now on this DT conversion and we still always find something. In most cases it should be just a question of configuring a board specific .dts file. I don't have all the boards though, so I've only done the ones I have naturally. Regards, Tony
* Tony Lindgren <tony@atomide.com> [131210 11:00]: > * Paul Walmsley <paul@pwsan.com> [131210 10:47]: > > > - The N800 isn't booting here with a concatenated uImage+dtb - but > > maybe I'm doing something wrong with this one. > > Hmm n800 works for me here for sure, I can n-uple check today. Yeah n800 boots just fine here. Will email you the dmesg. Tony
* Tony Lindgren <tony@atomide.com> [131210 11:00]: > * Paul Walmsley <paul@pwsan.com> [131210 10:47]: > > On Mon, 9 Dec 2013, Tony Lindgren wrote: > > > > > The following changes since commit f2e2c9d9b4087b74eb9e00d8dfac148354cb0b71: > > > > > > ARM: dts: Fix booting for secure omaps (2013-12-06 15:30:43 -0800) > > > > > > are available in the git repository at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.14/omap3-board-removal-signed > > > > > > for you to fetch changes up to 736e812636ea72be444b85fa7e92554967459069: > > > > > > ARM: OMAP2+: Remove unused platform init code and headers (2013-12-08 14:15:46 -0800) > > > > The description in Tony's pull request below alludes to what regressions > > will occur when this is pulled. But just to state it in terms of what > > happened on the local testbed here when I tried it: > > > > - CM-T3517 booting will break since there's no .dts file for it. Are > > there other boards that will be affected here too? > > Yeah the cm-t3770 is on my todo list, but I've left it last as it's my > home router and has been behaving quite nicely. > > That should then cover: > > SBC-T3530 > http://compulab.co.il/products/sbcs/sbc-t3530/ > > SBC-T3517 > http://compulab.co.il/products/sbcs/sbc-t3517/ > > SBC-T3730 > http://compulab.co.il/products/sbcs/sbc-t3730/ > > They all seem to have the same baseboard, and the CPU module is > different. So getting the 3530 and 3517 variants working should > be trivial. I don't have 3530 or 3517 variants, so somebody else > will need to do those two. > > And Nishant just posted a .dts file for the 3517 craneboard. And here's a list of other boards we don't have .dts file for if people have these: board-devkit8000.c omap3-ldp.dts or omap3-beagle.dts is a good starting point board-omap3logic.c omap3-ldp.dts or omap3-beagle.dts is a good starting point board-omap3pandora.c omap3-ldp.dts or omap3-beagle.dts is a good starting point board-omap3stalker.c board-omap3touchbook.c For the ones above, omap3-ldp.dts or omap3-beagle.dts are good starting points. There's the DPI display pdata patch too, but it seems we want to wait to see if Tomi gets his display changes done before applying that. I don't have any of the ones above, so people using those please do the .dts files ASAP. Or send me those boards with working boot loaders and I'll do them at a rate of one board per day or so.. And then you're stuck with my criteria of "usable" which is usually serial port and NFS root unless I really like the board, mhuwahuaaaahh! board-ti8168evm.c I doubt ti8168evm has even worked for a long time.. It's in pretty sorry state unfortunately with missing clock support and missing handle_irq entry in the board-ti8168evm.c. Regards, Tony
On Tuesday 10 December 2013, Tony Lindgren wrote: > board-ti8168evm.c > > I doubt ti8168evm has even worked for a long time.. It's in pretty > sorry state unfortunately with missing clock support and missing > handle_irq entry in the board-ti8168evm.c. Does that imply the entire ti81xx soc support is lacking, or just that board specifically? It seems to be the only board file that ever got merged. Arnd
On Tue, 10 Dec 2013, Arnd Bergmann wrote: > On Tuesday 10 December 2013, Tony Lindgren wrote: > > board-ti8168evm.c > > > > I doubt ti8168evm has even worked for a long time.. It's in pretty > > sorry state unfortunately with missing clock support and missing > > handle_irq entry in the board-ti8168evm.c. > > Does that imply the entire ti81xx soc support is lacking, or just > that board specifically? It seems to be the only board file that > ever got merged. We don't really support in mainline for 8148/8168 chips, so this is not much of a regression. TI gave up trying to upstream it several years ago. Aida Mynzhasova <aida.mynzhasova@skitlab.ru> has done some work on this recently, but I don't know what the current status is. Maybe she can comment. - Paul
* Arnd Bergmann <arnd@arndb.de> [131210 11:41]: > On Tuesday 10 December 2013, Tony Lindgren wrote: > > board-ti8168evm.c > > > > I doubt ti8168evm has even worked for a long time.. It's in pretty > > sorry state unfortunately with missing clock support and missing > > handle_irq entry in the board-ti8168evm.c. > > Does that imply the entire ti81xx soc support is lacking, or just > that board specifically? It seems to be the only board file that > ever got merged. It's an omap3 variant and it's still waiting for the clock patches that now unfortunately have a dependency to the the omap clock move to drivers/clk. Aida Mynzhasova posted some patches few months ago here: http://www.spinics.net/lists/linux-omap/msg96341.html Since it's an omap3 variant, we should be able to make it usable quite easily, so no need to remove the whole support at least yet. Plus it seems to be an active TI part, so people are still it. But it's definitely not a show stopper for making omap3 to boot in device tree only mode. Regards, Tony
* Tony Lindgren <tony@atomide.com> [131210 09:01]: > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131210 08:08]: > > > > Right, so I should just turn off building OMAP3 for the remainder of this > > cycle. > > > > What's the fscking point me running a build system, because if I switch > > it now, OMAP3 breaks. If I don't switch it now and your pull request is > > merged, it breaks at that point. > > Fair enough, I hear you. > > > This is utterly insane. > > Well let's do this. Let's merge the parts that add stuff now, then wait > a week (or longer as needed) so you have both ways working with linux > next for a while. Does that sounds reasonable to you? OK I've added a tag to the same branch earlier before we remove any of the legacy omap3 support and sent a new pull request. Regards, Tony
* Tony Lindgren <tony@atomide.com> [131210 11:28]: > * Tony Lindgren <tony@atomide.com> [131210 11:00]: > > * Paul Walmsley <paul@pwsan.com> [131210 10:47]: > > > On Mon, 9 Dec 2013, Tony Lindgren wrote: > > > > > > > The following changes since commit f2e2c9d9b4087b74eb9e00d8dfac148354cb0b71: > > > > > > > > ARM: dts: Fix booting for secure omaps (2013-12-06 15:30:43 -0800) > > > > > > > > are available in the git repository at: > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.14/omap3-board-removal-signed > > > > > > > > for you to fetch changes up to 736e812636ea72be444b85fa7e92554967459069: > > > > > > > > ARM: OMAP2+: Remove unused platform init code and headers (2013-12-08 14:15:46 -0800) > > > > > > The description in Tony's pull request below alludes to what regressions > > > will occur when this is pulled. But just to state it in terms of what > > > happened on the local testbed here when I tried it: > > > > > > - CM-T3517 booting will break since there's no .dts file for it. Are > > > there other boards that will be affected here too? > > > > Yeah the cm-t3770 is on my todo list, but I've left it last as it's my > > home router and has been behaving quite nicely. > > > > That should then cover: > > > > SBC-T3530 > > http://compulab.co.il/products/sbcs/sbc-t3530/ > > > > SBC-T3517 > > http://compulab.co.il/products/sbcs/sbc-t3517/ > > > > SBC-T3730 > > http://compulab.co.il/products/sbcs/sbc-t3730/ > > > > They all seem to have the same baseboard, and the CPU module is > > different. So getting the 3530 and 3517 variants working should > > be trivial. I don't have 3530 or 3517 variants, so somebody else > > will need to do those two. > > > > And Nishant just posted a .dts file for the 3517 craneboard. > > And here's a list of other boards we don't have .dts file for if > people have these: > > board-devkit8000.c omap3-ldp.dts or omap3-beagle.dts is a good starting point Oops, sorry this one we already have covered with omap3-devkit8000.dts. And please ignore the multiple comments, they all are pretty close to omap3-ldp and omap3-beagle. > board-omap3logic.c omap3-ldp.dts or omap3-beagle.dts is a good starting point > board-omap3pandora.c omap3-ldp.dts or omap3-beagle.dts is a good starting point > board-omap3stalker.c > board-omap3touchbook.c > > For the ones above, omap3-ldp.dts or omap3-beagle.dts are good starting > points. There's the DPI display pdata patch too, but it seems we want to > wait to see if Tomi gets his display changes done before applying that. > > I don't have any of the ones above, so people using those please > do the .dts files ASAP. > > Or send me those boards with working boot loaders and I'll do them at > a rate of one board per day or so.. And then you're stuck with my > criteria of "usable" which is usually serial port and NFS root unless > I really like the board, mhuwahuaaaahh! > > board-ti8168evm.c > > I doubt ti8168evm has even worked for a long time.. It's in pretty > sorry state unfortunately with missing clock support and missing > handle_irq entry in the board-ti8168evm.c. > > Regards, > > Tony
On Tue, 10 Dec 2013, Tony Lindgren wrote: > * Paul Walmsley <paul@pwsan.com> [131210 10:47]: > > > - The N800 isn't booting here with a concatenated uImage+dtb - but > > maybe I'm doing something wrong with this one. > > Hmm n800 works for me here for sure, I can n-uple check today. The N800 here is booting now with this series. My mistake, as suspected... > > Best if the pull request were to explicitly state the known > > regressions with this series, in terms of specific boards and > > configurations. That way, people will know what to expect. > > Well ideally we would have no regressions when doing this, but I've > been chasing people and bugs for few years now on this DT conversion > and we still always find something. In most cases it should be just > a question of configuring a board specific .dts file. I don't have > all the boards though, so I've only done the ones I have naturally. Yeah some level of regression is expected with this, for sure. It's just good to have it documented if it's known. - Paul
* Tony Lindgren <tony@atomide.com> [131210 15:08]: > * Tony Lindgren <tony@atomide.com> [131210 11:28]: > > * Tony Lindgren <tony@atomide.com> [131210 11:00]: > > > * Paul Walmsley <paul@pwsan.com> [131210 10:47]: > > > > On Mon, 9 Dec 2013, Tony Lindgren wrote: > > > > > > > > > The following changes since commit f2e2c9d9b4087b74eb9e00d8dfac148354cb0b71: > > > > > > > > > > ARM: dts: Fix booting for secure omaps (2013-12-06 15:30:43 -0800) > > > > > > > > > > are available in the git repository at: > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.14/omap3-board-removal-signed > > > > > > > > > > for you to fetch changes up to 736e812636ea72be444b85fa7e92554967459069: > > > > > > > > > > ARM: OMAP2+: Remove unused platform init code and headers (2013-12-08 14:15:46 -0800) > > > > > > > > The description in Tony's pull request below alludes to what regressions > > > > will occur when this is pulled. But just to state it in terms of what > > > > happened on the local testbed here when I tried it: > > > > > > > > - CM-T3517 booting will break since there's no .dts file for it. Are > > > > there other boards that will be affected here too? > > > > > > Yeah the cm-t3770 is on my todo list, but I've left it last as it's my > > > home router and has been behaving quite nicely. > > > > > > That should then cover: > > > > > > SBC-T3530 > > > http://compulab.co.il/products/sbcs/sbc-t3530/ > > > > > > SBC-T3517 > > > http://compulab.co.il/products/sbcs/sbc-t3517/ > > > > > > SBC-T3730 > > > http://compulab.co.il/products/sbcs/sbc-t3730/ > > > > > > They all seem to have the same baseboard, and the CPU module is > > > different. So getting the 3530 and 3517 variants working should > > > be trivial. I don't have 3530 or 3517 variants, so somebody else > > > will need to do those two. OK posted a patch for the SBC-T3730 with minimal support also for SBC-3530 and SBC-3517 that should boot far enough to start adding more devices. Paul, care to try it on the CM-T3517, the patch is: [PATCH] ARM: dts: Add support for sbc-3xxx with cm-t3730 Let's hope there's two smsc911x devices also on the 3517 based board, otherwise it should have a completely separate .dts file. > > > And Nishant just posted a .dts file for the 3517 craneboard. > > > > And here's a list of other boards we don't have .dts file for if > > people have these: > > > > board-devkit8000.c omap3-ldp.dts or omap3-beagle.dts is a good starting point > > Oops, sorry this one we already have covered with omap3-devkit8000.dts. > And please ignore the multiple comments, they all are pretty close to > omap3-ldp and omap3-beagle. > > > board-omap3logic.c omap3-ldp.dts or omap3-beagle.dts is a good starting point > > board-omap3pandora.c omap3-ldp.dts or omap3-beagle.dts is a good starting point > > board-omap3stalker.c > > board-omap3touchbook.c > > > > For the ones above, omap3-ldp.dts or omap3-beagle.dts are good starting > > points. There's the DPI display pdata patch too, but it seems we want to > > wait to see if Tomi gets his display changes done before applying that. > > > > I don't have any of the ones above, so people using those please > > do the .dts files ASAP. > > > > Or send me those boards with working boot loaders and I'll do them at > > a rate of one board per day or so.. And then you're stuck with my > > criteria of "usable" which is usually serial port and NFS root unless > > I really like the board, mhuwahuaaaahh! > > > > board-ti8168evm.c > > > > I doubt ti8168evm has even worked for a long time.. It's in pretty > > sorry state unfortunately with missing clock support and missing > > handle_irq entry in the board-ti8168evm.c. > > > > Regards, > > > > Tony
On Fri, 13 Dec 2013, Tony Lindgren wrote: > OK posted a patch for the SBC-T3730 with minimal support also for > SBC-3530 and SBC-3517 that should boot far enough to start adding > more devices. Paul, care to try it on the CM-T3517, the patch is: > > [PATCH] ARM: dts: Add support for sbc-3xxx with cm-t3730 Didn't get anything out of the serial port: http://www.pwsan.com/omap/testlogs/test_tonys_conversion_v3.14/20131215235827/boot/cmt3517/cmt3517_log.txt As a partial sanity check, AM3517 EVM was included as part of the run (with a separate uImage+dtb of course) and that seems to boot OK: http://www.pwsan.com/omap/testlogs/test_tonys_conversion_v3.14/20131215235827/boot/3517evm/3517evm_log.txt In case it's useful, here's a CM-T3517 boot log from v3.13-rc4: http://www.pwsan.com/omap/testlogs/test_v3.13-rc4/20131215195251/boot/cmt3517/cmt3517_log.txt - Paul
* Paul Walmsley <paul@pwsan.com> [131216 23:16]: > On Fri, 13 Dec 2013, Tony Lindgren wrote: > > > OK posted a patch for the SBC-T3730 with minimal support also for > > SBC-3530 and SBC-3517 that should boot far enough to start adding > > more devices. Paul, care to try it on the CM-T3517, the patch is: > > > > [PATCH] ARM: dts: Add support for sbc-3xxx with cm-t3730 > > Didn't get anything out of the serial port: > > http://www.pwsan.com/omap/testlogs/test_tonys_conversion_v3.14/20131215235827/boot/cmt3517/cmt3517_log.txt OK thanks for testing. Looks like the CompuLab guys will need to take a look at it. I'll update my patch for SBC-T3730 only with the comments from Igor. > As a partial sanity check, AM3517 EVM was included as part of the run > (with a separate uImage+dtb of course) and that seems to boot OK: > > http://www.pwsan.com/omap/testlogs/test_tonys_conversion_v3.14/20131215235827/boot/3517evm/3517evm_log.txt Hmm OK, weird that the 3517 EVM boots but not the CM-T3517. > In case it's useful, here's a CM-T3517 boot log from v3.13-rc4: > > http://www.pwsan.com/omap/testlogs/test_v3.13-rc4/20131215195251/boot/cmt3517/cmt3517_log.txt OK thanks. Tony
The following changes since commit f2e2c9d9b4087b74eb9e00d8dfac148354cb0b71: ARM: dts: Fix booting for secure omaps (2013-12-06 15:30:43 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.14/omap3-board-removal-signed for you to fetch changes up to 736e812636ea72be444b85fa7e92554967459069: ARM: OMAP2+: Remove unused platform init code and headers (2013-12-08 14:15:46 -0800) ---------------------------------------------------------------- We can now finally make mach-omap2 to boot with device tree only and get rid of over 20k lines of platform init code that way. Most basic devices already work using device tree based initialization and the remaining devices can be initialized using platform data with pdata-quirks.c. So for most missing boards it's just a question of adding a .dts file that should be fairly similar to one of the existing .dts files as we've tried to cover all basic omap3 board types. For people getting started updating their board files to for device tree, there are some basic instructions in commit 8dc8b3ddf5d7 (ARM: OMAP2+: Remove legacy omap3 board-*.c files and make mach-omap2 DT only for booting). Please also note that there are also some related fixes making their way into the mainline kernel that are needed for some use cases: PM off-idle for omap3 and wake-up events need the following two patches: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts http://lkml.org/lkml/2013/11/22/520 [PATCH] ARM: dts: Fix omap serial wake-up when booted with device tree http://www.spinics.net/lists/devicetree/msg13374.html EMAC Ethernet on am3517 boards needs: [PATCH] net: davinci_emac: Fix platform data handling and make usable for am3517 http://patchwork.ozlabs.org/patch/296351/ Ethernet for boards using smc91x needs: [PATCH v2] net: smc91x: Fix device tree based configuration so it's usable http://www.spinics.net/lists/netdev/msg258913.html ---------------------------------------------------------------- Aaro Koskinen (1): ARM: OMAP2+: dts: add n8x0 onenand Javier Martinez Canillas (3): ARM: OMAP2+: Remove legacy smsc911x and smc91x GPMC support ARM: OMAP2+: Remove unnecesary include in GPMC driver ARM: OMAP2+: Remove legacy board-flash.c Tony Lindgren (34): mfd: twl-core: Fix passing of platform data in the device tree case Merge branch 'dt-regressions' into omap-for-v3.13/fixes-take4 ARM: dts: Add basic device tree support for omap2430 sdp ARM: dts: Add basic Nokia N8X0 support ARM: dts: Add basic support for omap3 LDP zoom1 labrador Merge branch 'omap-for-v3.13/fixes-take4' into omap-for-v3.14/board-removal Merge branch 'omap-for-v3.14/dt' into omap-for-v3.14/board-removal ARM: OMAP2+: Add support for board specific auxdata quirks ARM: OMAP2+: Add device tree compatible revision checks for n8x0 ARM: OMAP2+: Make n8x0 behave better with device tree based booting ARM: OMAP2+: Add quirks support for n8x0 ARM: OMAP2+: Remove legacy booting support for n8x0 ARM: OMAP2+: Remove board file for H4 ARM: OMAP2+: Remove legacy board file for 2430sdp ARM: OMAP2+: Remove legacy mux code for omap2 ARM: OMAP2+: Remove legacy hwmod entries for omap2 Merge branch 'omap-for-v3.14/board-removal' into omap-for-v3.14/omap3-board-removal ARM: OMAP2+: Add support for legacy auxdata for twl ARM: OMAP2+: Use pdata quirks for emac on am3517 ARM: dts: Add basic devices on am3517-evm ARM: OMAP2+: Remove legacy omap3 board-*.c files and make mach-omap2 DT only for booting ARM: OMAP2+: Remove legacy serial.c ARM: OMAP2+: Remove legacy hsmmc.c ARM: OMAP2+: Remove legacy i2c.c platform init code ARM: OMAP2+: Remove legacy PM init ARM: OMAP2+: Remove legacy twl4030 platform init code ARM: OMAP2+: Remove legacy usb-host.c platform init code ARM: OMAP2+: Remove legacy muxing for usb-tusb6010.c ARM: OMAP2+: Remove legacy usb-musb.c platform init code ARM: OMAP2+: Remove legacy hwmod mux code ARM: OMAP2+: Remove legacy mux code ARM: OMAP2+: Remove legacy data from hwmod for omap3 ARM: OMAP2+: Remove legacy emac code ARM: OMAP2+: Remove unused platform init code and headers arch/arm/boot/dts/Makefile | 5 + arch/arm/boot/dts/am3517-evm.dts | 29 + arch/arm/boot/dts/omap2420-n800.dts | 8 + arch/arm/boot/dts/omap2420-n810-wimax.dts | 8 + arch/arm/boot/dts/omap2420-n810.dts | 8 + arch/arm/boot/dts/omap2420-n8x0-common.dtsi | 99 + arch/arm/boot/dts/omap2430-sdp.dts | 49 + arch/arm/boot/dts/omap3-ldp.dts | 231 +++ arch/arm/mach-omap1/Kconfig | 26 + arch/arm/mach-omap1/i2c.c | 83 + arch/arm/mach-omap2/Kconfig | 125 -- arch/arm/mach-omap2/Makefile | 51 +- arch/arm/mach-omap2/am33xx-restart.c | 2 - arch/arm/mach-omap2/am35xx-emac.c | 115 -- arch/arm/mach-omap2/am35xx-emac.h | 15 - arch/arm/mach-omap2/board-2430sdp.c | 273 --- arch/arm/mach-omap2/board-3430sdp.c | 633 ------ arch/arm/mach-omap2/board-am3517crane.c | 150 -- arch/arm/mach-omap2/board-am3517evm.c | 379 ---- arch/arm/mach-omap2/board-cm-t35.c | 771 -------- arch/arm/mach-omap2/board-cm-t3517.c | 337 ---- arch/arm/mach-omap2/board-devkit8000.c | 655 ------- arch/arm/mach-omap2/board-flash.c | 245 --- arch/arm/mach-omap2/board-flash.h | 62 - arch/arm/mach-omap2/board-h4.c | 365 ---- arch/arm/mach-omap2/board-ldp.c | 425 ---- arch/arm/mach-omap2/board-n8x0.c | 239 +-- arch/arm/mach-omap2/board-omap3beagle.c | 596 ------ arch/arm/mach-omap2/board-omap3logic.c | 251 --- arch/arm/mach-omap2/board-omap3pandora.c | 630 ------ arch/arm/mach-omap2/board-omap3stalker.c | 438 ----- arch/arm/mach-omap2/board-omap3touchbook.c | 396 ---- arch/arm/mach-omap2/board-overo.c | 572 ------ arch/arm/mach-omap2/board-rx51-peripherals.c | 1323 ------------- arch/arm/mach-omap2/board-rx51-video.c | 67 - arch/arm/mach-omap2/board-rx51.c | 142 -- arch/arm/mach-omap2/board-rx51.h | 11 - arch/arm/mach-omap2/board-ti8168evm.c | 62 - arch/arm/mach-omap2/common-board-devices.h | 3 +- arch/arm/mach-omap2/common.h | 16 +- arch/arm/mach-omap2/devices.c | 34 - arch/arm/mach-omap2/dss-common.c | 1 - arch/arm/mach-omap2/gpmc-smc91x.c | 186 -- arch/arm/mach-omap2/gpmc-smc91x.h | 42 - arch/arm/mach-omap2/gpmc-smsc911x.c | 100 - arch/arm/mach-omap2/gpmc-smsc911x.h | 35 - arch/arm/mach-omap2/gpmc.c | 1 - arch/arm/mach-omap2/hsmmc.c | 518 ----- arch/arm/mach-omap2/hsmmc.h | 53 - arch/arm/mach-omap2/i2c.c | 97 - arch/arm/mach-omap2/i2c.h | 13 - arch/arm/mach-omap2/include/mach/serial.h | 66 - arch/arm/mach-omap2/io.c | 2 - arch/arm/mach-omap2/msdi.c | 70 - arch/arm/mach-omap2/mux.c | 1161 ----------- arch/arm/mach-omap2/mux.h | 357 ---- arch/arm/mach-omap2/mux2420.c | 690 ------- arch/arm/mach-omap2/mux2420.h | 282 --- arch/arm/mach-omap2/mux2430.c | 793 -------- arch/arm/mach-omap2/mux2430.h | 370 ---- arch/arm/mach-omap2/mux34xx.c | 2061 -------------------- arch/arm/mach-omap2/mux34xx.h | 402 ---- arch/arm/mach-omap2/omap4-keypad.h | 8 - arch/arm/mach-omap2/omap_device.c | 2 + arch/arm/mach-omap2/omap_hwmod.c | 160 +- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 147 -- arch/arm/mach-omap2/omap_hwmod_2430_data.c | 274 --- .../omap_hwmod_2xxx_3xxx_interconnect_data.c | 134 +- .../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c | 201 +- .../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 166 +- arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 72 +- .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 7 - arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 854 +------- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 8 - arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 10 - arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 10 - arch/arm/mach-omap2/omap_hwmod_common_data.h | 5 - arch/arm/mach-omap2/omap_twl.c | 314 --- arch/arm/mach-omap2/pdata-quirks.c | 107 +- arch/arm/mach-omap2/pm.c | 164 +- arch/arm/mach-omap2/serial.c | 335 ---- arch/arm/mach-omap2/serial.h | 1 - arch/arm/mach-omap2/twl-common.c | 570 ------ arch/arm/mach-omap2/twl-common.h | 66 - arch/arm/mach-omap2/usb-host.c | 496 ----- arch/arm/mach-omap2/usb-musb.c | 114 -- arch/arm/mach-omap2/usb-tusb6010.c | 21 - arch/arm/plat-omap/Kconfig | 26 - arch/arm/plat-omap/Makefile | 3 - arch/arm/plat-omap/i2c.c | 116 -- drivers/mfd/twl-core.c | 15 +- 91 files changed, 773 insertions(+), 20862 deletions(-) create mode 100644 arch/arm/boot/dts/omap2420-n800.dts create mode 100644 arch/arm/boot/dts/omap2420-n810-wimax.dts create mode 100644 arch/arm/boot/dts/omap2420-n810.dts create mode 100644 arch/arm/boot/dts/omap2420-n8x0-common.dtsi create mode 100644 arch/arm/boot/dts/omap2430-sdp.dts create mode 100644 arch/arm/boot/dts/omap3-ldp.dts delete mode 100644 arch/arm/mach-omap2/am35xx-emac.c delete mode 100644 arch/arm/mach-omap2/am35xx-emac.h delete mode 100644 arch/arm/mach-omap2/board-2430sdp.c delete mode 100644 arch/arm/mach-omap2/board-3430sdp.c delete mode 100644 arch/arm/mach-omap2/board-am3517crane.c delete mode 100644 arch/arm/mach-omap2/board-am3517evm.c delete mode 100644 arch/arm/mach-omap2/board-cm-t35.c delete mode 100644 arch/arm/mach-omap2/board-cm-t3517.c delete mode 100644 arch/arm/mach-omap2/board-devkit8000.c delete mode 100644 arch/arm/mach-omap2/board-flash.c delete mode 100644 arch/arm/mach-omap2/board-flash.h delete mode 100644 arch/arm/mach-omap2/board-h4.c delete mode 100644 arch/arm/mach-omap2/board-ldp.c delete mode 100644 arch/arm/mach-omap2/board-omap3beagle.c delete mode 100644 arch/arm/mach-omap2/board-omap3logic.c delete mode 100644 arch/arm/mach-omap2/board-omap3pandora.c delete mode 100644 arch/arm/mach-omap2/board-omap3stalker.c delete mode 100644 arch/arm/mach-omap2/board-omap3touchbook.c delete mode 100644 arch/arm/mach-omap2/board-overo.c delete mode 100644 arch/arm/mach-omap2/board-rx51-peripherals.c delete mode 100644 arch/arm/mach-omap2/board-rx51-video.c delete mode 100644 arch/arm/mach-omap2/board-rx51.c delete mode 100644 arch/arm/mach-omap2/board-rx51.h delete mode 100644 arch/arm/mach-omap2/board-ti8168evm.c delete mode 100644 arch/arm/mach-omap2/gpmc-smc91x.c delete mode 100644 arch/arm/mach-omap2/gpmc-smc91x.h delete mode 100644 arch/arm/mach-omap2/gpmc-smsc911x.c delete mode 100644 arch/arm/mach-omap2/gpmc-smsc911x.h delete mode 100644 arch/arm/mach-omap2/hsmmc.c delete mode 100644 arch/arm/mach-omap2/hsmmc.h delete mode 100644 arch/arm/mach-omap2/include/mach/serial.h delete mode 100644 arch/arm/mach-omap2/mux.c delete mode 100644 arch/arm/mach-omap2/mux.h delete mode 100644 arch/arm/mach-omap2/mux2420.c delete mode 100644 arch/arm/mach-omap2/mux2420.h delete mode 100644 arch/arm/mach-omap2/mux2430.c delete mode 100644 arch/arm/mach-omap2/mux2430.h delete mode 100644 arch/arm/mach-omap2/mux34xx.c delete mode 100644 arch/arm/mach-omap2/mux34xx.h delete mode 100644 arch/arm/mach-omap2/omap4-keypad.h delete mode 100644 arch/arm/mach-omap2/omap_twl.c delete mode 100644 arch/arm/mach-omap2/serial.c delete mode 100644 arch/arm/mach-omap2/serial.h delete mode 100644 arch/arm/mach-omap2/twl-common.c delete mode 100644 arch/arm/mach-omap2/twl-common.h delete mode 100644 arch/arm/mach-omap2/usb-host.c delete mode 100644 arch/arm/mach-omap2/usb-musb.c delete mode 100644 arch/arm/plat-omap/i2c.c