| Message ID | 1391730137-14814-22-git-send-email-andrew@lunn.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Dear Andrew Lunn, On Fri, 7 Feb 2014 00:42:17 +0100, Andrew Lunn wrote: > Now that all the device tree support is in mach-mvebu, remove it from > mach-kirkwood. > > Regenerate kirkwood_defconfig, removing all DT support, and a couple > of other redundent options have been removed in the process. > > Signed-off-by: Andrew Lunn <andrew@lunn.ch> > --- > arch/arm/configs/kirkwood_defconfig | 6 - So after this series we have a mvebu_defconfig that only builds the ARMv7 platforms of mach-mvebu. I believe this may look strange to people looking at the code, seeing that Kirkwood DT support is in mach-mvebu, but that mvebu_defconfig doesn't work to build a Kirkwood kernel. I don't really have a solution, except maybe having mvebu_v7_defconfig and mvebu_v5_defconfig to build only the Marvell v7 and Marvell v5 platforms. Best regards, Thomas
On Fri, Feb 07, 2014 at 09:33:13AM +0100, Thomas Petazzoni wrote: > Dear Andrew Lunn, > > On Fri, 7 Feb 2014 00:42:17 +0100, Andrew Lunn wrote: > > Now that all the device tree support is in mach-mvebu, remove it from > > mach-kirkwood. > > > > Regenerate kirkwood_defconfig, removing all DT support, and a couple > > of other redundent options have been removed in the process. > > > > Signed-off-by: Andrew Lunn <andrew@lunn.ch> > > --- > > arch/arm/configs/kirkwood_defconfig | 6 - > > So after this series we have a mvebu_defconfig that only builds the > ARMv7 platforms of mach-mvebu. I believe this may look strange to > people looking at the code, seeing that Kirkwood DT support is in > mach-mvebu, but that mvebu_defconfig doesn't work to build a Kirkwood > kernel. > > I don't really have a solution, except maybe having mvebu_v7_defconfig > and mvebu_v5_defconfig to build only the Marvell v7 and Marvell v5 > platforms. Hi Thomas I also have no solution, other than what you suggested. I think it also goes against the rules for a platform to have multiple _defconfig files. We probably do have a good cause to go against the rules thought. Lets wait and see what ARM SOC maintainers suggest. Andrew
On Fri, Feb 07, 2014 at 09:33:13AM +0100, Thomas Petazzoni wrote: > Dear Andrew Lunn, > > On Fri, 7 Feb 2014 00:42:17 +0100, Andrew Lunn wrote: > > Now that all the device tree support is in mach-mvebu, remove it from > > mach-kirkwood. > > > > Regenerate kirkwood_defconfig, removing all DT support, and a couple > > of other redundent options have been removed in the process. > > > > Signed-off-by: Andrew Lunn <andrew@lunn.ch> > > --- > > arch/arm/configs/kirkwood_defconfig | 6 - > > So after this series we have a mvebu_defconfig that only builds the > ARMv7 platforms of mach-mvebu. I believe this may look strange to > people looking at the code, seeing that Kirkwood DT support is in > mach-mvebu, but that mvebu_defconfig doesn't work to build a Kirkwood > kernel. > > I don't really have a solution, except maybe having mvebu_v7_defconfig > and mvebu_v5_defconfig to build only the Marvell v7 and Marvell v5 > platforms. Ideally, I'd prefer multi_v7 and multi_v5 for DT, and {kirkwood,dove,orion5x,mv78xx0}_defconfig for non-DT legacy building. The latter going away once we deprecate non-DT booting. There is a case to be made for the arch-specific defconfigs, though. Currently (includes modules if configured, and dtbs); mvebu_defconfig 00:02:56 x86_64_defconfig 00:04:24 multi_v7_defconfig 00:04:05 1 minute and 9 seconds doesn't drastically change a bathroom break or tea time ;-) But it is a 33% increase. If we want something leaner than multi_v7, how about armada_370-xp_defconfig to replace the current mvebu_defconfig? kirkwood_defconfig could enable ARCH_KIRKWOOD and MACH_KIRKWOOD until we remove legacy boot. Same with dove_defconfig and the others. thx, Jason.
Dear Jason Cooper, On Fri, 7 Feb 2014 10:03:06 -0500, Jason Cooper wrote: > Ideally, I'd prefer multi_v7 and multi_v5 for DT, and > {kirkwood,dove,orion5x,mv78xx0}_defconfig for non-DT legacy building. > The latter going away once we deprecate non-DT booting. There is a case > to be made for the arch-specific defconfigs, though. > > Currently (includes modules if configured, and dtbs); > > mvebu_defconfig 00:02:56 > x86_64_defconfig 00:04:24 > multi_v7_defconfig 00:04:05 > > 1 minute and 9 seconds doesn't drastically change a bathroom break or > tea time ;-) But it is a 33% increase. I also like to have a more focused defconfig than multi_v7 for development. > If we want something leaner than multi_v7, how about > armada_370-xp_defconfig to replace the current mvebu_defconfig? Doesn't work for me: we're going to introduce soon the support for other mvebu ARMv7 SoC that are not Armada 370 nor XP, but that should be built as part of this. Why not mvebu_v7 and mvebu_v5 as I suggested? mvebu_v7 would build both Dove and Armada 370/XP (and the other ones we are going to introduce soon), mvebu_v5 would build Kirkwood (and possibly Orion5x once I find enough time to work on this platform). This way, ultimately we can simply remove kirkwood_defconfig and dove_defconfig, as soon as all legacy platforms have been either converted to DT, or removed. Best regards, Thomas
On Fri, Feb 07, 2014 at 04:09:54PM +0100, Thomas Petazzoni wrote: > Dear Jason Cooper, > > On Fri, 7 Feb 2014 10:03:06 -0500, Jason Cooper wrote: > > > Ideally, I'd prefer multi_v7 and multi_v5 for DT, and > > {kirkwood,dove,orion5x,mv78xx0}_defconfig for non-DT legacy building. > > The latter going away once we deprecate non-DT booting. There is a case > > to be made for the arch-specific defconfigs, though. > > > > Currently (includes modules if configured, and dtbs); > > > > mvebu_defconfig 00:02:56 > > x86_64_defconfig 00:04:24 > > multi_v7_defconfig 00:04:05 > > > > 1 minute and 9 seconds doesn't drastically change a bathroom break or > > tea time ;-) But it is a 33% increase. > > I also like to have a more focused defconfig than multi_v7 for > development. > > > If we want something leaner than multi_v7, how about > > armada_370-xp_defconfig to replace the current mvebu_defconfig? > > Doesn't work for me: we're going to introduce soon the support for > other mvebu ARMv7 SoC that are not Armada 370 nor XP, but that should > be built as part of this. > > Why not mvebu_v7 and mvebu_v5 as I suggested? mvebu_v7 would build both > Dove and Armada 370/XP (and the other ones we are going to introduce > soon), mvebu_v5 would build Kirkwood (and possibly Orion5x once I find > enough time to work on this platform). Yeah, I can go with that, as long as Sebastian doesn't see a need for a separate dove_defconfig in the long term (DT only). Sebastian? > This way, ultimately we can simply remove kirkwood_defconfig and > dove_defconfig, as soon as all legacy platforms have been either > converted to DT, or removed. Yep, the fewer builds I have to do per patch submission, the better. thx, Jason.
On 02/07/2014 04:15 PM, Jason Cooper wrote: > On Fri, Feb 07, 2014 at 04:09:54PM +0100, Thomas Petazzoni wrote: >> On Fri, 7 Feb 2014 10:03:06 -0500, Jason Cooper wrote: >>> If we want something leaner than multi_v7, how about >>> armada_370-xp_defconfig to replace the current mvebu_defconfig? >> >> Doesn't work for me: we're going to introduce soon the support for >> other mvebu ARMv7 SoC that are not Armada 370 nor XP, but that should >> be built as part of this. >> >> Why not mvebu_v7 and mvebu_v5 as I suggested? mvebu_v7 would build both >> Dove and Armada 370/XP (and the other ones we are going to introduce >> soon), mvebu_v5 would build Kirkwood (and possibly Orion5x once I find >> enough time to work on this platform). > > Yeah, I can go with that, as long as Sebastian doesn't see a need for a > separate dove_defconfig in the long term (DT only). Sebastian? Nope, I have no plans to keep a special dove_defconfig for Dove in mach-mvebu. >> This way, ultimately we can simply remove kirkwood_defconfig and >> dove_defconfig, as soon as all legacy platforms have been either >> converted to DT, or removed. > > Yep, the fewer builds I have to do per patch submission, the better. Sounds good to me. Sebastian
On 02/07/2014 12:42 AM, Andrew Lunn wrote: > Now that all the device tree support is in mach-mvebu, remove it from > mach-kirkwood. > > Regenerate kirkwood_defconfig, removing all DT support, and a couple > of other redundent options have been removed in the process. > > Signed-off-by: Andrew Lunn <andrew@lunn.ch> > --- Hmm, I wonder what Ian thinks of removing this so quickly again... Maybe let it rot for 1-2 kernel versions? Sebastian
On Fri, Feb 07, 2014 at 06:34:26PM +0100, Sebastian Hesselbarth wrote: > On 02/07/2014 12:42 AM, Andrew Lunn wrote: > >Now that all the device tree support is in mach-mvebu, remove it from > >mach-kirkwood. > > > >Regenerate kirkwood_defconfig, removing all DT support, and a couple > >of other redundent options have been removed in the process. > > > >Signed-off-by: Andrew Lunn <andrew@lunn.ch> > >--- > > Hmm, I wonder what Ian thinks of removing this so quickly again... > > Maybe let it rot for 1-2 kernel versions? The easiest answer is to modify kirkwood_defconfig to select both ARCH_KIRKWOOD and MACH_KIRKWOOD until such time as we have a working dts file for _every_ board file. Only then should we look at beginning the deprecation process for non-DT. thx, Jason.
> Why not mvebu_v7 and mvebu_v5 as I suggested? mvebu_v7 would build both > Dove and Armada 370/XP (and the other ones we are going to introduce > soon), mvebu_v5 would build Kirkwood (and possibly Orion5x once I find > enough time to work on this platform). Hi Thomas Could you produce a patch moving mvebu_defconfig to mvebu_v7_defconfig? I will generate the mvebu_v5_defconfig based on kirkwood_defconfig as part of my patchset. Thanks Andrew > > This way, ultimately we can simply remove kirkwood_defconfig and > dove_defconfig, as soon as all legacy platforms have been either > converted to DT, or removed. > > Best regards, > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com
On Fri, 2014-02-07 at 18:34 +0100, Sebastian Hesselbarth wrote: > On 02/07/2014 12:42 AM, Andrew Lunn wrote: > > Now that all the device tree support is in mach-mvebu, remove it from > > mach-kirkwood. > > > > Regenerate kirkwood_defconfig, removing all DT support, and a couple s/DT/board-file/? > > of other redundent options have been removed in the process. > > > > Signed-off-by: Andrew Lunn <andrew@lunn.ch> > > --- > > Hmm, I wonder what Ian thinks of removing this so quickly again... I don't want to stand in the way of progress. What version is this targeting so I can setup our tooling to DTRT and append a DTB under the correct circumstances. I still need to figure out how to distinguish the variations, but I think I have a plan there (via which PCI buses are present, which is a bit skanky but seems like the most workable solution). Ian. > Maybe let it rot for 1-2 kernel versions? > > Sebastian > >
On Thu, Feb 20, 2014 at 10:30:17AM +0000, Ian Campbell wrote: > On Fri, 2014-02-07 at 18:34 +0100, Sebastian Hesselbarth wrote: > > On 02/07/2014 12:42 AM, Andrew Lunn wrote: > > > Now that all the device tree support is in mach-mvebu, remove it from > > > mach-kirkwood. > > > > > > Regenerate kirkwood_defconfig, removing all DT support, and a couple > > s/DT/board-file/? We keep any system using -setup.c files, and remove the ability to boot systems with a DT description. Thus mach-kirkwood becomes legacy, and you should now be trying to only use mach-mvebu, compiled for v5 systems and a second compile for v7 systems. There are four systems left in mach-kirkwood which don't have DT equivalent. These are LaCie 2Big and 5Big, HP t5325 thin client and Marvell OpenRD machines. I'm working on t5325 and Openrd. The sticking point is audio support, which no other board has done with DT yet. The two LeCie boards have a custom LED driver which needs a DT binding. My gut feeling is that we won't get these four converted to DT in time for 3.15. > > > of other redundent options have been removed in the process. > > > > > > Signed-off-by: Andrew Lunn <andrew@lunn.ch> > > > --- > > > > Hmm, I wonder what Ian thinks of removing this so quickly again... > > I don't want to stand in the way of progress. What version is this > targeting so I can setup our tooling to DTRT and append a DTB under the > correct circumstances. My aim is 3.15. Most patches have been Acked now, so i think we are on track for that. > I still need to figure out how to distinguish the variations, but I > think I have a plan there (via which PCI buses are present, which is a > bit skanky but seems like the most workable solution). Having the SoC ID available via lspci for systems using the new PCI driver might be in 3.14. It was considered a regression so might get merged into an rc. If not, it will be in 3.15. We have also talked about putting the SOC version and revision into /proc/cpuinfo, in the Revision field. However this has not happened yet. Andrew
On Thu, Feb 20, 2014 at 11:58:54AM +0100, Andrew Lunn wrote: > On Thu, Feb 20, 2014 at 10:30:17AM +0000, Ian Campbell wrote: > > On Fri, 2014-02-07 at 18:34 +0100, Sebastian Hesselbarth wrote: > > > On 02/07/2014 12:42 AM, Andrew Lunn wrote: > > > > Now that all the device tree support is in mach-mvebu, remove it from > > > > mach-kirkwood. > > > > > > > > Regenerate kirkwood_defconfig, removing all DT support, and a couple > > > > s/DT/board-file/? > > We keep any system using -setup.c files, and remove the ability to > boot systems with a DT description. Thus mach-kirkwood becomes legacy, > and you should now be trying to only use mach-mvebu, compiled for v5 > systems and a second compile for v7 systems. > > There are four systems left in mach-kirkwood which don't have DT > equivalent. These are LaCie 2Big and 5Big, HP t5325 thin client and > Marvell OpenRD machines. I'm working on t5325 and Openrd. The sticking > point is audio support, which no other board has done with DT yet. > The two LeCie boards have a custom LED driver which needs a DT > binding. My gut feeling is that we won't get these four converted to > DT in time for 3.15. > > > > > of other redundent options have been removed in the process. > > > > > > > > Signed-off-by: Andrew Lunn <andrew@lunn.ch> > > > > --- > > > > > > Hmm, I wonder what Ian thinks of removing this so quickly again... > > > > I don't want to stand in the way of progress. What version is this > > targeting so I can setup our tooling to DTRT and append a DTB under the > > correct circumstances. > > My aim is 3.15. Most patches have been Acked now, so i think we are on > track for that. > > > > I still need to figure out how to distinguish the variations, but I > > think I have a plan there (via which PCI buses are present, which is a > > bit skanky but seems like the most workable solution). > > Having the SoC ID available via lspci for systems using the new PCI > driver might be in 3.14. It was considered a regression so might get > merged into an rc. If not, it will be in 3.15. > > We have also talked about putting the SOC version and revision into > /proc/cpuinfo, in the Revision field. However this has not happened > yet. NAK. What's wrong with the soc subsystem (drivers/base/soc.c). This provides a way to export SoC through standardised interfaces.
On Thu, Feb 20, 2014 at 11:19:14AM +0000, Russell King - ARM Linux wrote: > > We have also talked about putting the SOC version and revision into > > /proc/cpuinfo, in the Revision field. However this has not happened > > yet. > > NAK. > > What's wrong with the soc subsystem (drivers/base/soc.c). This provides > a way to export SoC through standardised interfaces. Hi Russell Thanks for the tip. We will do this. Andrew
(adding debian-arm/-kernel) On Thu, 2014-02-20 at 11:58 +0100, Andrew Lunn wrote: > On Thu, Feb 20, 2014 at 10:30:17AM +0000, Ian Campbell wrote: > > On Fri, 2014-02-07 at 18:34 +0100, Sebastian Hesselbarth wrote: > > > On 02/07/2014 12:42 AM, Andrew Lunn wrote: > > > > Now that all the device tree support is in mach-mvebu, remove it from > > > > mach-kirkwood. > > > > > > > > Regenerate kirkwood_defconfig, removing all DT support, and a couple > > > > s/DT/board-file/? > > We keep any system using -setup.c files, and remove the ability to > boot systems with a DT description. Thus mach-kirkwood becomes legacy, > and you should now be trying to only use mach-mvebu, compiled for v5 > systems and a second compile for v7 systems. Just to check I've got it: The majority of the systems previously supported by mach-kirkwood (either board file or DTB based) are now supported by mach-mvebu. Is it possible to have both ARCH_KIRKWOOD and ARCH_MVEBU in the same v5 .config? IOW that all of the platforms currently supported by the Debian kirkwood flavour remain supportable in the same binary after this change. It looks like it should be to me, but I'm not 100% sure. If not then Debian will need to introduce a new kernel flavour and manage the transition somehow, which is going to be tricky if we need to retain both flavours. Is there a tree I can pull to see what is going into v3.15 in this area? > There are four systems left in mach-kirkwood which don't have DT > equivalent. These are LaCie 2Big and 5Big, HP t5325 thin client and > Marvell OpenRD machines. I'm working on t5325 and Openrd. The sticking > point is audio support, which no other board has done with DT yet. > The two LeCie boards have a custom LED driver which needs a DT > binding. My gut feeling is that we won't get these four converted to > DT in time for 3.15. > > > > > of other redundent options have been removed in the process. > > > > > > > > Signed-off-by: Andrew Lunn <andrew@lunn.ch> > > > > --- > > > > > > Hmm, I wonder what Ian thinks of removing this so quickly again... > > > > I don't want to stand in the way of progress. What version is this > > targeting so I can setup our tooling to DTRT and append a DTB under the > > correct circumstances. > > My aim is 3.15. Most patches have been Acked now, so i think we are on > track for that. If kirkwood and mvebu are mutually exclusive on v5 then this sounds like it might end up being more complicated than just setting Append-DTB-From in the flash-kernel db. In that case if we could hold off on pulling the existing kirkwood support until there is a transition plan here I'd be very grateful. Ian.
On Thu, 2014-02-20 at 11:19 +0000, Russell King - ARM Linux wrote: > What's wrong with the soc subsystem (drivers/base/soc.c). This > provides a way to export SoC through standardised interfaces. It looks like the thing to use to me. It seems to have been around only since v3.3 though, which makes it a bit tricky to use when upgrading from running board-file based v3.2 system (Debian Wheezy) to a newer DTB based kernel, we need to select the new DTB while running the old system. I'd prefer to use this thing as the primary mechanism but it seems like I'd have to implement some sort of fallback at least for one Debian release cycle. I'm sure it is doable... Ian.
On Thursday 20 February 2014 11:58:54 Andrew Lunn wrote: > > > I still need to figure out how to distinguish the variations, but I > > think I have a plan there (via which PCI buses are present, which is a > > bit skanky but seems like the most workable solution). > > Having the SoC ID available via lspci for systems using the new PCI > driver might be in 3.14. It was considered a regression so might get > merged into an rc. If not, it will be in 3.15. > > We have also talked about putting the SOC version and revision into > /proc/cpuinfo, in the Revision field. However this has not happened > yet. Another option would be to use the soc bus to provide that information in /sys/devices/soc, and put the rest of the devices under that node. Arnd
On Thu, Feb 20, 2014 at 11:34:36AM +0000, Ian Campbell wrote: > (adding debian-arm/-kernel) > On Thu, 2014-02-20 at 11:58 +0100, Andrew Lunn wrote: > > On Thu, Feb 20, 2014 at 10:30:17AM +0000, Ian Campbell wrote: > > > On Fri, 2014-02-07 at 18:34 +0100, Sebastian Hesselbarth wrote: > > > > On 02/07/2014 12:42 AM, Andrew Lunn wrote: > > > > > Now that all the device tree support is in mach-mvebu, remove it from > > > > > mach-kirkwood. > > > > > > > > > > Regenerate kirkwood_defconfig, removing all DT support, and a couple > > > > > > s/DT/board-file/? > > > > We keep any system using -setup.c files, and remove the ability to > > boot systems with a DT description. Thus mach-kirkwood becomes legacy, > > and you should now be trying to only use mach-mvebu, compiled for v5 > > systems and a second compile for v7 systems. > > Just to check I've got it: The majority of the systems previously > supported by mach-kirkwood (either board file or DTB based) are now > supported by mach-mvebu. We plan to move all kirkwood systems which are DT to mach-mvebu. Any systems which are not DT will get left in mach-kirkwood. What would be interesting to know is, if any of the systems left behind are supported by debian. So LaCie 2Big and 5Big, HP t5325 thin client and Marvell OpenRD machines? If you don't support any of these, you can drop mach-kirkwood. > Is it possible to have both ARCH_KIRKWOOD and ARCH_MVEBU in the same > v5 .config? Armada XP, 370, and the new SoCs going in this cycle all use ARM v7 CPUs. Dove also uses an ARM v7 cpu and we intent to move it from mach-dove into mach-mvebu. Now ARM v7 cpu and ARM v5 CPUs are mutually incompatible. You cannot combine them into one kernel. Do you currently build mach-mvebu as part of a multi v7 kernel. That is, you have one kernel which boots on all v7 machines? What this patchset does is also make mach-mvebu part of the multi v5 kernel. So you just need one kernel for all ARM v5 machines which are part of multi v5. The long term goal is that you need just two 32 ARM kernels, multi v5 and multi v7. However orion5x and mv76xx0 are not yet part of theses, so we are not there yet. > IOW that all of the platforms currently supported by the > Debian kirkwood flavour remain supportable in the same binary after this > change. It looks like it should be to me, but I'm not 100% sure. If you don't support LaCie 2Big and 5Big, HP t5325 thin client and Marvell OpenRD then yes, you have one binary. That binary could potentially support over v5 machines, but i have no idea what ARM machines Debian actually supports. Is there a list somewhere? > Is there a tree I can pull to see what is going into v3.15 in this > area? At the moment there is not a tree with all the different parts. I have a tree with these specific patches. There are other trees which contain new DT descriptions for new devices, like Bubba B3, and systems which have been converted to DT, like the QNAP T4xx. > > My aim is 3.15. Most patches have been Acked now, so i think we are on > > track for that. > > If kirkwood and mvebu are mutually exclusive on v5 then this sounds like > it might end up being more complicated than just setting Append-DTB-From > in the flash-kernel db. In that case if we could hold off on pulling the > existing kirkwood support until there is a transition plan here I'd be > very grateful. Lets make sure we are all on the same page with v5, v7, kirkwood, mvebu, multi, and what kernels Debian currently builds and how flash-kernel works etc. We can then discuss transition plans. Andrew
On Thu, 2014-02-20 at 13:18 +0100, Andrew Lunn wrote: > On Thu, Feb 20, 2014 at 11:34:36AM +0000, Ian Campbell wrote: > > (adding debian-arm/-kernel) > > On Thu, 2014-02-20 at 11:58 +0100, Andrew Lunn wrote: > > > On Thu, Feb 20, 2014 at 10:30:17AM +0000, Ian Campbell wrote: > > > > On Fri, 2014-02-07 at 18:34 +0100, Sebastian Hesselbarth wrote: > > > > > On 02/07/2014 12:42 AM, Andrew Lunn wrote: > > > > > > Now that all the device tree support is in mach-mvebu, remove it from > > > > > > mach-kirkwood. > > > > > > > > > > > > Regenerate kirkwood_defconfig, removing all DT support, and a couple > > > > > > > > s/DT/board-file/? > > > > > > We keep any system using -setup.c files, and remove the ability to > > > boot systems with a DT description. Thus mach-kirkwood becomes legacy, > > > and you should now be trying to only use mach-mvebu, compiled for v5 > > > systems and a second compile for v7 systems. > > > > Just to check I've got it: The majority of the systems previously > > supported by mach-kirkwood (either board file or DTB based) are now > > supported by mach-mvebu. > > We plan to move all kirkwood systems which are DT to mach-mvebu. Any > systems which are not DT will get left in mach-kirkwood. > > What would be interesting to know is, if any of the systems left > behind are supported by debian. So LaCie 2Big and 5Big, HP t5325 thin > client and Marvell OpenRD machines? If you don't support any of these, > you can drop mach-kirkwood. > > > Is it possible to have both ARCH_KIRKWOOD and ARCH_MVEBU in the same > > v5 .config? > > Armada XP, 370, and the new SoCs going in this cycle all use ARM v7 > CPUs. Dove also uses an ARM v7 cpu and we intent to move it from > mach-dove into mach-mvebu. > > Now ARM v7 cpu and ARM v5 CPUs are mutually incompatible. You cannot > combine them into one kernel. Do you currently build mach-mvebu as > part of a multi v7 kernel. That is, you have one kernel which boots on > all v7 machines? Debian has a single v7 flavour, armmp which uses the multi platform stuff. (actually there is a second armmp-lpae, but lets ignore that) I'm only really concerned about the v5 stuff here. Debian has multiple v5 flavours: ixp4xx, kirkwood, mv78xx0, orion5x and versatile. > What this patchset does is also make mach-mvebu part of the multi v5 > kernel. So you just need one kernel for all ARM v5 machines which are > part of multi v5. The long term goal is that you need just two 32 ARM > kernels, multi v5 and multi v7. However orion5x and mv76xx0 are not > yet part of theses, so we are not there yet. So in answer to my question, on v5 ARCH_KIRKWOOD and ARCH_MVEBU *cannot* coexist in the same binary? > > IOW that all of the platforms currently supported by the > > Debian kirkwood flavour remain supportable in the same binary after this > > change. It looks like it should be to me, but I'm not 100% sure. > > If you don't support LaCie 2Big and 5Big, HP t5325 thin client and > Marvell OpenRD then yes, you have one binary. That binary could > potentially support over v5 machines, but i have no idea what ARM > machines Debian actually supports. Is there a list somewhere? http://anonscm.debian.org/gitweb/?p=d-i/flash-kernel.git;a=blob;f=db/all.db;h=fab340782c783c4f8a172f0424a791037dee90cf;hb=HEAD is a reasonable approximation for what is supported, at least in a well integrated way. I can see all of the LaCie systems, t5325 and openrd stuff which you mention in that list. http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/config/armel/config.kirkwood?revision=20912&view=markup is the kirkwood specific kernel config s/trunk/wheezy/ if you want to see the current stable version. Other config.* for other flavours. I'm only concerned with the impact of these changes on the kirkwood flavour right now, I don't want to confuse the matter by considering the possibility of consolidating flavours. Ian. > > > Is there a tree I can pull to see what is going into v3.15 in this > > area? > > At the moment there is not a tree with all the different parts. I > have a tree with these specific patches. There are other trees which > contain new DT descriptions for new devices, like Bubba B3, and > systems which have been converted to DT, like the QNAP T4xx. > > > > My aim is 3.15. Most patches have been Acked now, so i think we are on > > > track for that. > > > > If kirkwood and mvebu are mutually exclusive on v5 then this sounds like > > it might end up being more complicated than just setting Append-DTB-From > > in the flash-kernel db. In that case if we could hold off on pulling the > > existing kirkwood support until there is a transition plan here I'd be > > very grateful. > > Lets make sure we are all on the same page with v5, v7, kirkwood, > mvebu, multi, and what kernels Debian currently builds and how > flash-kernel works etc. We can then discuss transition plans. > > Andrew >
On Thursday 20 February 2014 13:18:21 Andrew Lunn wrote: > > What this patchset does is also make mach-mvebu part of the multi v5 > kernel. So you just need one kernel for all ARM v5 machines which are > part of multi v5. The long term goal is that you need just two 32 ARM > kernels, multi v5 and multi v7. However orion5x and mv76xx0 are not > yet part of theses, so we are not there yet. BTW, if converting enough of orion5x to DT takes too long to deprecate that platform any time soon, I'd prefer moving it over to multiplatform while keeping the legacy board files in there. That should get substantially easier once mv78xx0, kirkwood and dove have been dealt with and we can collapse plat-orion and mach-orion5x into one directory. > > IOW that all of the platforms currently supported by the > > Debian kirkwood flavour remain supportable in the same binary after this > > change. It looks like it should be to me, but I'm not 100% sure. > > If you don't support LaCie 2Big and 5Big, HP t5325 thin client and > Marvell OpenRD then yes, you have one binary. That binary could > potentially support over v5 machines, but i have no idea what ARM > machines Debian actually supports. Is there a list somewhere? http://anonscm.debian.org/viewvc/kernel/releases/linux/3.12.9-1/debian/config/armel/config.kirkwood?view=markup just lists all kirkwood machines as enabled, but that of course doesn't meant they are actually working or supported. Arnd
> > What this patchset does is also make mach-mvebu part of the multi v5 > > kernel. So you just need one kernel for all ARM v5 machines which are > > part of multi v5. The long term goal is that you need just two 32 ARM > > kernels, multi v5 and multi v7. However orion5x and mv76xx0 are not > > yet part of theses, so we are not there yet. > > So in answer to my question, on v5 ARCH_KIRKWOOD and ARCH_MVEBU *cannot* > coexist in the same binary? Clearly ARCH_MVEBU v7 cannot. What i need to determine is if ARCH_KIRKWOOD and ARCH_MVEBU v5 will go into one binary. I _think_ the answer is no, but i need to take a closer look. What i suspect we will end up doing it dropping the last patch for the moment and ensuring ARCH_KIRKWOOD still supports all the DT machines. I think that just needs care with arch/arm/boot/dts/Makefile. Once we have the last four converted over to DT, you can then do a straight swap, mach-kirkwood for mach-mvebu. I will get back to you in a couple of days once i have this all figured out. Andrew
On Thursday 20 February 2014 12:51:04 Ian Campbell wrote: > On Thu, 2014-02-20 at 13:18 +0100, Andrew Lunn wrote: > > On Thu, Feb 20, 2014 at 11:34:36AM +0000, Ian Campbell wrote: > Debian has a single v7 flavour, armmp which uses the multi platform > stuff. (actually there is a second armmp-lpae, but lets ignore that) > > I'm only really concerned about the v5 stuff here. Debian has multiple > v5 flavours: ixp4xx, kirkwood, mv78xx0, orion5x and versatile. Unfortunately, this selection include multiple platforms that we don't plan to (ever) support in a multiplatform kernel, while a lot of platforms you don't currently support are already enabled or will be at some point. * ixp4xx is too different from the others and I don't think it's possible to turn it over to multiplatform. * I see a iop32x_defconfig in svn that you didn't mention here, but it's basically the same problem as ixp4xx. * kirkwood/mv78xx0/orion5x are essentially one platform and work in progress. * versatile is easy to do as multiplatform, I just haven't gotten around to do it. ARMv5 platforms that are already working with ARCH_MULTIPLATFORM: * freescale mxc (i.mx21 and i.mx25) * freescale mxs (i.mx23 and i.mx28) * st-ericsson Nomadik * st-ericsson u300 * st spear3xx * st spear6xx * TI NSpire * VIA/Wondermedia vt85xx/wm85xx/wm86xx The embedded mxs family is probably most interesting among these, but there is also a community around the wondermedia stuff, which is used in cheap tablets and laptops. > > What this patchset does is also make mach-mvebu part of the multi v5 > > kernel. So you just need one kernel for all ARM v5 machines which are > > part of multi v5. The long term goal is that you need just two 32 ARM > > kernels, multi v5 and multi v7. However orion5x and mv76xx0 are not > > yet part of theses, so we are not there yet. > > So in answer to my question, on v5 ARCH_KIRKWOOD and ARCH_MVEBU *cannot* > coexist in the same binary? That has been the plan for the kirkwood migration for the last few years, yes. The idea is that every kirkwood machine that anyone is interested in should be supported by ARCH_MVEBU, and we can keep ARCH_KIRKWOOD for the ones we don't care about until it is just dropped. Same for orion5x, dove and mv78xx0, just a different schedule for moving them over. Now in theory, we could have them supported in a multiplatform kernel, but that would mean extra work that we planned to avoid by converting them to DT first. As I said, it may be useful to do multiplatform support for MACH_ORION5x, but for MACH_KIRKWOOD, we have come too far now to turn back. Arnd
On Thu, 2014-02-20 at 14:53 +0100, Arnd Bergmann wrote: > On Thursday 20 February 2014 12:51:04 Ian Campbell wrote: > > On Thu, 2014-02-20 at 13:18 +0100, Andrew Lunn wrote: > > > On Thu, Feb 20, 2014 at 11:34:36AM +0000, Ian Campbell wrote: > > Debian has a single v7 flavour, armmp which uses the multi platform > > stuff. (actually there is a second armmp-lpae, but lets ignore that) > > > > I'm only really concerned about the v5 stuff here. Debian has multiple > > v5 flavours: ixp4xx, kirkwood, mv78xx0, orion5x and versatile. > > Unfortunately, this selection include multiple platforms that > we don't plan to (ever) support in a multiplatform kernel, while > a lot of platforms you don't currently support are already enabled > or will be at some point. That's ok, Debian is happy to stick with separate flavours for v5 if necessary for the existing ones, although I think we'd prefer to avoid adding any new ones. (for v7 we have gone multiplatform only already) > * ixp4xx is too different from the others and I don't think it's > possible to turn it over to multiplatform. > * I see a iop32x_defconfig in svn that you didn't mention here, > but it's basically the same problem as ixp4xx. This is only in Wheezy and not in trunk (which will become Jessie). AIUI support for these has been dropped for the next version of Debian so Wheezy is the last one and we don't need to worry about upgrade for these. TBH I'm not sure that ixp4xx isn't in the same boat, I suppose we'll see. > * kirkwood/mv78xx0/orion5x are essentially one platform and work > in progress. > * versatile is easy to do as multiplatform, I just haven't gotten > around to do it. > > ARMv5 platforms that are already working with ARCH_MULTIPLATFORM: > * freescale mxc (i.mx21 and i.mx25) > * freescale mxs (i.mx23 and i.mx28) > * st-ericsson Nomadik > * st-ericsson u300 > * st spear3xx > * st spear6xx > * TI NSpire > * VIA/Wondermedia vt85xx/wm85xx/wm86xx > > The embedded mxs family is probably most interesting among these, > but there is also a community around the wondermedia stuff, which is > used in cheap tablets and laptops. Interesting. I don't know how many of these are supported by Debian -- mostly these things get added when someone acquires one and scratches that itch. I suppose if we could remove at least one existing flavour in favour of a v5 multiplatform config then there probably wouldn't be many objections to doing that. > > > What this patchset does is also make mach-mvebu part of the multi v5 > > > kernel. So you just need one kernel for all ARM v5 machines which are > > > part of multi v5. The long term goal is that you need just two 32 ARM > > > kernels, multi v5 and multi v7. However orion5x and mv76xx0 are not > > > yet part of theses, so we are not there yet. > > > > So in answer to my question, on v5 ARCH_KIRKWOOD and ARCH_MVEBU *cannot* > > coexist in the same binary? > > That has been the plan for the kirkwood migration for the last few > years, yes. The idea is that every kirkwood machine that anyone is > interested in should be supported by ARCH_MVEBU, and we can keep > ARCH_KIRKWOOD for the ones we don't care about until it is just > dropped. > > Same for orion5x, dove and mv78xx0, just a different schedule > for moving them over. > > Now in theory, we could have them supported in a multiplatform kernel, > but that would mean extra work that we planned to avoid by converting > them to DT first. > > As I said, it may be useful to do multiplatform support for MACH_ORION5x, > but for MACH_KIRKWOOD, we have come too far now to turn back. Understood. It sounds like mach-kirkwood is very close to being removable altogether though (by migrating the last few boards to mach-mvebu), which would make distro upgrades much simpler, since we can just do a straight swap rather than trying to figure out which one we need. Ian.
On Thu, 2014-02-20 at 14:04 +0100, Arnd Bergmann wrote: > On Thursday 20 February 2014 13:18:21 Andrew Lunn wrote: > > > IOW that all of the platforms currently supported by the > > > Debian kirkwood flavour remain supportable in the same binary after this > > > change. It looks like it should be to me, but I'm not 100% sure. > > > > If you don't support LaCie 2Big and 5Big, HP t5325 thin client and > > Marvell OpenRD then yes, you have one binary. That binary could > > potentially support over v5 machines, but i have no idea what ARM > > machines Debian actually supports. Is there a list somewhere? > > http://anonscm.debian.org/viewvc/kernel/releases/linux/3.12.9-1/debian/config/armel/config.kirkwood?view=markup > > just lists all kirkwood machines as enabled, but that of course > doesn't meant they are actually working or supported. In general boards get added there by someone who is running Debian on that platform. We don't really have any way to tell what platforms people are actually using. Ian.
On Thu, 2014-02-20 at 14:23 +0100, Andrew Lunn wrote: > > > What this patchset does is also make mach-mvebu part of the multi v5 > > > kernel. So you just need one kernel for all ARM v5 machines which are > > > part of multi v5. The long term goal is that you need just two 32 ARM > > > kernels, multi v5 and multi v7. However orion5x and mv76xx0 are not > > > yet part of theses, so we are not there yet. > > > > So in answer to my question, on v5 ARCH_KIRKWOOD and ARCH_MVEBU *cannot* > > coexist in the same binary? > > Clearly ARCH_MVEBU v7 cannot. Yes, sorry, I meant v5 ARCH_KIRKWOOD and v5 ARCH_MVEBU. > What i need to determine is if > ARCH_KIRKWOOD and ARCH_MVEBU v5 will go into one binary. I _think_ the > answer is no, but i need to take a closer look. Arnd has said no too. > What i suspect we will end up doing it dropping the last patch for the > moment and ensuring ARCH_KIRKWOOD still supports all the DT machines. > I think that just needs care with arch/arm/boot/dts/Makefile. > > Once we have the last four converted over to DT, you can then do a > straight swap, mach-kirkwood for mach-mvebu. That sounds like a good plan, thanks! If we are going to do a straight swap I suppose it might as go for a v5 multiplatform flavour instead of a mvebu specific one. > I will get back to you in a couple of days once i have this all > figured out. Thank you. Ian.
On Thursday 20 February 2014 14:21:10 Ian Campbell wrote: > On Thu, 2014-02-20 at 14:53 +0100, Arnd Bergmann wrote: > > On Thursday 20 February 2014 12:51:04 Ian Campbell wrote: > > * ixp4xx is too different from the others and I don't think it's > > possible to turn it over to multiplatform. > > * I see a iop32x_defconfig in svn that you didn't mention here, > > but it's basically the same problem as ixp4xx. > > This is only in Wheezy and not in trunk (which will become Jessie). AIUI > support for these has been dropped for the next version of Debian so > Wheezy is the last one and we don't need to worry about upgrade for > these. Ok, I see. > TBH I'm not sure that ixp4xx isn't in the same boat, I suppose we'll > see. For all I know, the only interesting ixp4xx platforms are the consumer products listed on http://www.nslu2-linux.org/, the other ones you support are development boards that tend to exist only in very small quantities. The main limitation would be the amount of installed RAM, which is either 32MB or 64MB depending on the machine for these. Running a modern Debian with these constraints is probably possible but doesn't sound like fun. ;-) Also, the upstream kernel port isn't that well maintained, a lot the development seems to have happened in OpenWRT and not mainlined, including a dozen new machines that were already ported in 2009. Then again, Martin Michlmayr has instructions for running Wheezy on the 32MB nslu2, and I guess as long as he's interested in the hardware, new versions of Debian will keep running on it. > > The embedded mxs family is probably most interesting among these, > > but there is also a community around the wondermedia stuff, which is > > used in cheap tablets and laptops. > > Interesting. I don't know how many of these are supported by Debian -- > mostly these things get added when someone acquires one and scratches > that itch. > > I suppose if we could remove at least one existing flavour in favour of > a v5 multiplatform config then there probably wouldn't be many > objections to doing that. That will probably come as a natural progression after kirkwood gets replaced with mvebu. > > As I said, it may be useful to do multiplatform support for MACH_ORION5x, > > but for MACH_KIRKWOOD, we have come too far now to turn back. > > Understood. It sounds like mach-kirkwood is very close to being > removable altogether though (by migrating the last few boards to > mach-mvebu), which would make distro upgrades much simpler, since we can > just do a straight swap rather than trying to figure out which one we > need. Yes, makes sense. Arnd
On Thu, Feb 20, 2014 at 11:58:54AM +0100, Andrew Lunn wrote: > On Thu, Feb 20, 2014 at 10:30:17AM +0000, Ian Campbell wrote: > > On Fri, 2014-02-07 at 18:34 +0100, Sebastian Hesselbarth wrote: > > > On 02/07/2014 12:42 AM, Andrew Lunn wrote: > > > > Now that all the device tree support is in mach-mvebu, remove it from > > > > mach-kirkwood. > > > > > > > > Regenerate kirkwood_defconfig, removing all DT support, and a couple > > > > s/DT/board-file/? > > We keep any system using -setup.c files, and remove the ability to > boot systems with a DT description. Thus mach-kirkwood becomes legacy, > and you should now be trying to only use mach-mvebu, compiled for v5 > systems and a second compile for v7 systems. > > There are four systems left in mach-kirkwood which don't have DT > equivalent. These are LaCie 2Big and 5Big, HP t5325 thin client and > Marvell OpenRD machines. I'm working on t5325 and Openrd. The sticking > point is audio support, which no other board has done with DT yet. > The two LeCie boards have a custom LED driver which needs a DT > binding. My gut feeling is that we won't get these four converted to > DT in time for 3.15. Why not do like we did when we started the kirkwood dt conversion? Create dts files for the remaining boards, and do if (of_machine_is_compatible(...)) legacy_audio_init() in board-v5.c? I suspect audio is going to take time to sort out. I'd hate to delay this just for that. thx, Jason.
On Thu, Feb 20, 2014 at 11:39:16AM +0000, Ian Campbell wrote: > On Thu, 2014-02-20 at 11:19 +0000, Russell King - ARM Linux wrote: > > What's wrong with the soc subsystem (drivers/base/soc.c). This > > provides a way to export SoC through standardised interfaces. > > It looks like the thing to use to me. > > It seems to have been around only since v3.3 though, which makes it a > bit tricky to use when upgrading from running board-file based v3.2 > system (Debian Wheezy) to a newer DTB based kernel, we need to select > the new DTB while running the old system. > > I'd prefer to use this thing as the primary mechanism but it seems like > I'd have to implement some sort of fallback at least for one Debian > release cycle. I'm sure it is doable... back in v3.2, lspci should still work. Would that given you the information you need? thx, Jason.
On Thu, 2014-02-20 at 16:19 +0100, Arnd Bergmann wrote: > On Thursday 20 February 2014 14:21:10 Ian Campbell wrote: > > On Thu, 2014-02-20 at 14:53 +0100, Arnd Bergmann wrote: > > > On Thursday 20 February 2014 12:51:04 Ian Campbell wrote: > > > * ixp4xx is too different from the others and I don't think it's > > > possible to turn it over to multiplatform. > > > * I see a iop32x_defconfig in svn that you didn't mention here, > > > but it's basically the same problem as ixp4xx. > > > > This is only in Wheezy and not in trunk (which will become Jessie). AIUI > > support for these has been dropped for the next version of Debian so > > Wheezy is the last one and we don't need to worry about upgrade for > > these. > > Ok, I see. > > > TBH I'm not sure that ixp4xx isn't in the same boat, I suppose we'll > > see. > > For all I know, the only interesting ixp4xx platforms are the consumer > products listed on http://www.nslu2-linux.org/, the other ones you support > are development boards that tend to exist only in very small quantities. > > The main limitation would be the amount of installed RAM, which is > either 32MB or 64MB depending on the machine for these. Running a > modern Debian with these constraints is probably possible but > doesn't sound like fun. ;-) Our most pressing constraint has actually been the size of the kernel partition in flash, which is only ~1.4 MB on some of the iop32x and ixp4xx machines (and ~1.5 MB on one of the orion5x machines). We've modularised as much as possible and turned off some of the features that are otherwise standard across all Debian architectures. But I got fed up with trying to make it fit, and no-one else stepped up to maintain the reduced configurations, so the last time iop32x went over the limit I removed it. As Ian hinted, ixp4xx might follow. > Also, the upstream kernel port isn't that well maintained, a lot > the development seems to have happened in OpenWRT and not mainlined, > including a dozen new machines that were already ported in 2009. > > Then again, Martin Michlmayr has instructions for running Wheezy > on the 32MB nslu2, and I guess as long as he's interested in the > hardware, new versions of Debian will keep running on it. [...] Martin is not currently active in Debian kernel maintenance. Ben.
On Thu, 2014-02-20 at 14:24 +0000, Ian Campbell wrote: > On Thu, 2014-02-20 at 14:23 +0100, Andrew Lunn wrote: [...] > > What i suspect we will end up doing it dropping the last patch for the > > moment and ensuring ARCH_KIRKWOOD still supports all the DT machines. > > I think that just needs care with arch/arm/boot/dts/Makefile. > > > > Once we have the last four converted over to DT, you can then do a > > straight swap, mach-kirkwood for mach-mvebu. > > That sounds like a good plan, thanks! > > If we are going to do a straight swap I suppose it might as go for a v5 > multiplatform flavour instead of a mvebu specific one. [...] I would love it if we could do that. By the way, we still have the problem that at least one supported orion5x machine (D-Link DNS-323) only has a ~1.5 MB kernel partition. So we would probably have to keep a reduced orion5x config for those machines, alongside the mvebu or multiplatform kernel. Ben.
On Friday 21 February 2014 01:47:31 Ben Hutchings wrote: > On Thu, 2014-02-20 at 16:19 +0100, Arnd Bergmann wrote: > > On Thursday 20 February 2014 14:21:10 Ian Campbell wrote: > > > For all I know, the only interesting ixp4xx platforms are the consumer > > products listed on http://www.nslu2-linux.org/, the other ones you support > > are development boards that tend to exist only in very small quantities. > > > > The main limitation would be the amount of installed RAM, which is > > either 32MB or 64MB depending on the machine for these. Running a > > modern Debian with these constraints is probably possible but > > doesn't sound like fun. > > Our most pressing constraint has actually been the size of the kernel > partition in flash, which is only ~1.4 MB on some of the iop32x and > ixp4xx machines (and ~1.5 MB on one of the orion5x machines). We've > modularised as much as possible and turned off some of the features that > are otherwise standard across all Debian architectures. Makes sense. I'm impressed you actually manage to get a modern kernel in 1.5MB and have it boot up a (mostly) full distro. I think we have in the past dropped a subarchitecture from the kernel when it turned out its defconfig could no longer fit within the 2MB of flash it has. > But I got fed up with trying to make it fit, and no-one else stepped up > to maintain the reduced configurations, so the last time iop32x went > over the limit I removed it. As Ian hinted, ixp4xx might follow. Ok. As I mentioned, I believe OpenWRT is really the playground for the remaining ixp4xx users that are doing new installs. Arnd
On Friday 21 February 2014 02:00:27 Ben Hutchings wrote: > On Thu, 2014-02-20 at 14:24 +0000, Ian Campbell wrote: > > On Thu, 2014-02-20 at 14:23 +0100, Andrew Lunn wrote: > [...] > > > What i suspect we will end up doing it dropping the last patch for the > > > moment and ensuring ARCH_KIRKWOOD still supports all the DT machines. > > > I think that just needs care with arch/arm/boot/dts/Makefile. > > > > > > Once we have the last four converted over to DT, you can then do a > > > straight swap, mach-kirkwood for mach-mvebu. > > > > That sounds like a good plan, thanks! > > > > If we are going to do a straight swap I suppose it might as go for a v5 > > multiplatform flavour instead of a mvebu specific one. > [...] > > I would love it if we could do that. > > By the way, we still have the problem that at least one supported > orion5x machine (D-Link DNS-323) only has a ~1.5 MB kernel partition. > So we would probably have to keep a reduced orion5x config for those > machines, alongside the mvebu or multiplatform kernel. orion5x is still some time away from being included in mvebu, 3.16 at the earliest, so it will have to stay separate anyway. My hope is really that we get very little overhead in enabling multiplatform on mvebu compared to a orion5x or kirkwood standalone configuration, so depending on what the platforms have you could end up with e.g. a 1.5MB "mini" multiplatform kernel that includes all machines that have 2MB or less for their kernel partitions and a "everything included" multiplatform kernel for the machines with larger partititons. For instance kirkwood-rd88f6281 has a 2MB uImage partition and everything else seems to have at least 4MB. Arnd
Dear Jason Cooper, On Thu, 20 Feb 2014 18:24:38 -0500, Jason Cooper wrote: > > We keep any system using -setup.c files, and remove the ability to > > boot systems with a DT description. Thus mach-kirkwood becomes legacy, > > and you should now be trying to only use mach-mvebu, compiled for v5 > > systems and a second compile for v7 systems. > > > > There are four systems left in mach-kirkwood which don't have DT > > equivalent. These are LaCie 2Big and 5Big, HP t5325 thin client and > > Marvell OpenRD machines. I'm working on t5325 and Openrd. The sticking > > point is audio support, which no other board has done with DT yet. > > The two LeCie boards have a custom LED driver which needs a DT > > binding. My gut feeling is that we won't get these four converted to > > DT in time for 3.15. > > Why not do like we did when we started the kirkwood dt conversion? > Create dts files for the remaining boards, and do > > if (of_machine_is_compatible(...)) > legacy_audio_init() > > in board-v5.c? > > I suspect audio is going to take time to sort out. I'd hate to delay > this just for that. Yes, I believe it's a good plan. Convert as much as possible to DT, and only keep those few devices (audio and leds) probe in an old-style fashion. This way, we can progressively add the necessary missing DT bindings. Best regards, Thomas
On Fri, Feb 21, 2014 at 02:07:40PM +0100, Arnd Bergmann wrote: > On Friday 21 February 2014 01:47:31 Ben Hutchings wrote: > > On Thu, 2014-02-20 at 16:19 +0100, Arnd Bergmann wrote: > > > On Thursday 20 February 2014 14:21:10 Ian Campbell wrote: > > > > > For all I know, the only interesting ixp4xx platforms are the consumer > > > products listed on http://www.nslu2-linux.org/, the other ones you support > > > are development boards that tend to exist only in very small quantities. > > > > > > The main limitation would be the amount of installed RAM, which is > > > either 32MB or 64MB depending on the machine for these. Running a > > > modern Debian with these constraints is probably possible but > > > doesn't sound like fun. > > > > Our most pressing constraint has actually been the size of the kernel > > partition in flash, which is only ~1.4 MB on some of the iop32x and > > ixp4xx machines (and ~1.5 MB on one of the orion5x machines). We've > > modularised as much as possible and turned off some of the features that > > are otherwise standard across all Debian architectures. > > Makes sense. I'm impressed you actually manage to get a modern kernel > in 1.5MB and have it boot up a (mostly) full distro. I think we have > in the past dropped a subarchitecture from the kernel when it turned > out its defconfig could no longer fit within the 2MB of flash it > has. > > > But I got fed up with trying to make it fit, and no-one else stepped up > > to maintain the reduced configurations, so the last time iop32x went > > over the limit I removed it. As Ian hinted, ixp4xx might follow. > > Ok. As I mentioned, I believe OpenWRT is really the playground for > the remaining ixp4xx users that are doing new installs. fwiw, I have two boards for this arch. NSLU2 and a Gateworks board. Both are ixp425 and both are gathering dust in a box. I probably don't have time to do anything with them. So, if Kevin or Olof wants to add them to the boot farm, or someone actually wants to boot test them, I would be willing to send them where ever. iirc, there are hacks to upgrade at least the RAM on the NSLU2. I'm pretty sure I maxed out the flash and the RAM on the Gateworks board when I ordered it. Also, the Gateworks board has 4 mini-pci slots (not pcie). Could be interesting. hth, Jason.
On Friday 21 February 2014 16:52:52 Thomas Petazzoni wrote: > On Thu, 20 Feb 2014 18:24:38 -0500, Jason Cooper wrote: > > > > We keep any system using -setup.c files, and remove the ability to > > > boot systems with a DT description. Thus mach-kirkwood becomes legacy, > > > and you should now be trying to only use mach-mvebu, compiled for v5 > > > systems and a second compile for v7 systems. > > > > > > There are four systems left in mach-kirkwood which don't have DT > > > equivalent. These are LaCie 2Big and 5Big, HP t5325 thin client and > > > Marvell OpenRD machines. I'm working on t5325 and Openrd. The sticking > > > point is audio support, which no other board has done with DT yet. > > > The two LeCie boards have a custom LED driver which needs a DT > > > binding. My gut feeling is that we won't get these four converted to > > > DT in time for 3.15. > > > > Why not do like we did when we started the kirkwood dt conversion? > > Create dts files for the remaining boards, and do > > > > if (of_machine_is_compatible(...)) > > legacy_audio_init() > > > > in board-v5.c? > > > > I suspect audio is going to take time to sort out. I'd hate to delay > > this just for that. > > Yes, I believe it's a good plan. Convert as much as possible to DT, and > only keep those few devices (audio and leds) probe in an old-style > fashion. > > This way, we can progressively add the necessary missing DT bindings. Makes sense. I'm also adding Simon Guinot to Cc here. He contributed both the kernel support and the Debian support for the LaCie 2Big/5Big. He might also be able to verify that they work after the DT conversion, or even help implementing it. Since there is already someone who is looking into t5325, that would just leave the OpenRD reference design, right? Arnd
> I'm also adding Simon Guinot to Cc here. He contributed both the kernel > support and the Debian support for the LaCie 2Big/5Big. He might also be > able to verify that they work after the DT conversion, or even help > implementing it. Since there is already someone who is looking into > t5325, that would just leave the OpenRD reference design, right? I'm onto both t5325 and OpenRD. Thomas provided me with a basic t5325 DTS file from around kernel version v3.5 which i have brought up to date. I'm now trying to get my head around ASOC and simple-card, i.e. do it properly using DT. OpenRD i'm at the same stage, just audio left, although i suspect i will get some interesting comments for how i handled command line parsing and enabling devices. I have a volunteer testing it, but feedback is slow. Andrew
On Fri, Feb 21, 2014 at 05:36:47PM +0100, Arnd Bergmann wrote: > On Friday 21 February 2014 16:52:52 Thomas Petazzoni wrote: > > On Thu, 20 Feb 2014 18:24:38 -0500, Jason Cooper wrote: > > > > > > We keep any system using -setup.c files, and remove the ability to > > > > boot systems with a DT description. Thus mach-kirkwood becomes legacy, > > > > and you should now be trying to only use mach-mvebu, compiled for v5 > > > > systems and a second compile for v7 systems. > > > > > > > > There are four systems left in mach-kirkwood which don't have DT > > > > equivalent. These are LaCie 2Big and 5Big, HP t5325 thin client and > > > > Marvell OpenRD machines. I'm working on t5325 and Openrd. The sticking > > > > point is audio support, which no other board has done with DT yet. > > > > The two LeCie boards have a custom LED driver which needs a DT > > > > binding. My gut feeling is that we won't get these four converted to > > > > DT in time for 3.15. > > > > > > Why not do like we did when we started the kirkwood dt conversion? > > > Create dts files for the remaining boards, and do > > > > > > if (of_machine_is_compatible(...)) > > > legacy_audio_init() > > > > > > in board-v5.c? > > > > > > I suspect audio is going to take time to sort out. I'd hate to delay > > > this just for that. > > > > Yes, I believe it's a good plan. Convert as much as possible to DT, and > > only keep those few devices (audio and leds) probe in an old-style > > fashion. > > > > This way, we can progressively add the necessary missing DT bindings. > > Makes sense. > > I'm also adding Simon Guinot to Cc here. He contributed both the kernel > support and the Debian support for the LaCie 2Big/5Big. He might also be > able to verify that they work after the DT conversion, or even help > implementing it. Since there is already someone who is looking into > t5325, that would just leave the OpenRD reference design, right? Yes. Although we are running short on time. I'd prefer not to rush Dashie, as he's brand new to the community. Also, Andrew has a Makefile solution he's working on to keep life manageable for debian for v3.15. We can take it out after the boards are converted with the above solution. It might even be fixes-non-critical for v3.16. thx, Jason.
On Fri, 2014-02-21 at 14:07 +0100, Arnd Bergmann wrote: > On Friday 21 February 2014 01:47:31 Ben Hutchings wrote: > > On Thu, 2014-02-20 at 16:19 +0100, Arnd Bergmann wrote: > > > On Thursday 20 February 2014 14:21:10 Ian Campbell wrote: > > > > > For all I know, the only interesting ixp4xx platforms are the consumer > > > products listed on http://www.nslu2-linux.org/, the other ones you support > > > are development boards that tend to exist only in very small quantities. > > > > > > The main limitation would be the amount of installed RAM, which is > > > either 32MB or 64MB depending on the machine for these. Running a > > > modern Debian with these constraints is probably possible but > > > doesn't sound like fun. > > > > Our most pressing constraint has actually been the size of the kernel > > partition in flash, which is only ~1.4 MB on some of the iop32x and > > ixp4xx machines (and ~1.5 MB on one of the orion5x machines). We've > > modularised as much as possible and turned off some of the features that > > are otherwise standard across all Debian architectures. > > Makes sense. I'm impressed you actually manage to get a modern kernel > in 1.5MB and have it boot up a (mostly) full distro. I think we have > in the past dropped a subarchitecture from the kernel when it turned > out its defconfig could no longer fit within the 2MB of flash it > has. [...] These are the changes we make for orion5x: # CONFIG_KPROBES is not set # CONFIG_CRYPTO_FIPS is not set # CONFIG_VGA_ARB is not set # CONFIG_AUDITSYSCALL is not set # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y #. Saves about 17K, and none of the quirks are likely to be needed # CONFIG_PCI_QUIRKS is not set # CONFIG_FTRACE is not set # CONFIG_KSM is not set CONFIG_IPV6=m # CONFIG_NET_MPLS_GSO is not set # CONFIG_NETLINK_MMAP is not set # CONFIG_SECURITY_YAMA is not set # CONFIG_RD_LZ4 is not set For ixp4xx we have these as well: #. Saves about 5K # CONFIG_USER_NS is not set #. Saves about 7K # CONFIG_MEMCG is not set #. Saves about 3K # CONFIG_BPF_JIT is not set (I think the built-in drivers for ixp4xx are smaller as well.) Ben.
On Fri, Feb 21, 2014 at 05:36:47PM +0100, Arnd Bergmann wrote: > On Friday 21 February 2014 16:52:52 Thomas Petazzoni wrote: > > On Thu, 20 Feb 2014 18:24:38 -0500, Jason Cooper wrote: > > > > > > We keep any system using -setup.c files, and remove the ability to > > > > boot systems with a DT description. Thus mach-kirkwood becomes legacy, > > > > and you should now be trying to only use mach-mvebu, compiled for v5 > > > > systems and a second compile for v7 systems. > > > > > > > > There are four systems left in mach-kirkwood which don't have DT > > > > equivalent. These are LaCie 2Big and 5Big, HP t5325 thin client and > > > > Marvell OpenRD machines. I'm working on t5325 and Openrd. The sticking > > > > point is audio support, which no other board has done with DT yet. > > > > The two LeCie boards have a custom LED driver which needs a DT > > > > binding. My gut feeling is that we won't get these four converted to > > > > DT in time for 3.15. > > > > > > Why not do like we did when we started the kirkwood dt conversion? > > > Create dts files for the remaining boards, and do > > > > > > if (of_machine_is_compatible(...)) > > > legacy_audio_init() > > > > > > in board-v5.c? > > > > > > I suspect audio is going to take time to sort out. I'd hate to delay > > > this just for that. > > > > Yes, I believe it's a good plan. Convert as much as possible to DT, and > > only keep those few devices (audio and leds) probe in an old-style > > fashion. > > > > This way, we can progressively add the necessary missing DT bindings. > > Makes sense. > > I'm also adding Simon Guinot to Cc here. He contributed both the kernel > support and the Debian support for the LaCie 2Big/5Big. He might also be > able to verify that they work after the DT conversion, or even help > implementing it. Since there is already someone who is looking into > t5325, that would just leave the OpenRD reference design, right? Hi Arnd, I am quite busy this days but as soon I get some free time I will take care of the DT conversion for the Lacie boards. Basically, we need to fix some minor issues with the Thomas patches: ARM: kirkwood: convert d2net_v2 to DT ARM: kirkwood: convert LaCie Net{2, 5}Big v2 platforms to DT And also a DT binding must be added to the LED driver leds-netxbig. Regards, Simon
On Thu, 2014-02-20 at 18:26 -0500, Jason Cooper wrote: > On Thu, Feb 20, 2014 at 11:39:16AM +0000, Ian Campbell wrote: > > On Thu, 2014-02-20 at 11:19 +0000, Russell King - ARM Linux wrote: > > > What's wrong with the soc subsystem (drivers/base/soc.c). This > > > provides a way to export SoC through standardised interfaces. > > > > It looks like the thing to use to me. > > > > It seems to have been around only since v3.3 though, which makes it a > > bit tricky to use when upgrading from running board-file based v3.2 > > system (Debian Wheezy) to a newer DTB based kernel, we need to select > > the new DTB while running the old system. > > > > I'd prefer to use this thing as the primary mechanism but it seems like > > I'd have to implement some sort of fallback at least for one Debian > > release cycle. I'm sure it is doable... > > back in v3.2, lspci should still work. Would that given you the > information you need? I expect it will, yes. Ian.
On Fri, 2014-02-21 at 02:00 +0000, Ben Hutchings wrote: > On Thu, 2014-02-20 at 14:24 +0000, Ian Campbell wrote: > > On Thu, 2014-02-20 at 14:23 +0100, Andrew Lunn wrote: > [...] > > > What i suspect we will end up doing it dropping the last patch for the > > > moment and ensuring ARCH_KIRKWOOD still supports all the DT machines. > > > I think that just needs care with arch/arm/boot/dts/Makefile. > > > > > > Once we have the last four converted over to DT, you can then do a > > > straight swap, mach-kirkwood for mach-mvebu. > > > > That sounds like a good plan, thanks! > > > > If we are going to do a straight swap I suppose it might as go for a v5 > > multiplatform flavour instead of a mvebu specific one. > [...] > > I would love it if we could do that. > > By the way, we still have the problem that at least one supported > orion5x machine (D-Link DNS-323) only has a ~1.5 MB kernel partition. > So we would probably have to keep a reduced orion5x config for those > machines, alongside the mvebu or multiplatform kernel. Sure. I think at worst we should aim to end up with as many flavour as we have today, in reality I expect we should be able to end up with fewer (even if only -= 1). BTW, someone (I forget who) at Debconf in Cambridge last year floated the idea of putting a stage 2 loader in flash to pull the real kernel from some larger storage. I don't know if that is realistic here, and in any case I don't intend to work on it myself. Ian.
> > > > What's wrong with the soc subsystem (drivers/base/soc.c). This > > > > provides a way to export SoC through standardised interfaces. > > > > > > It looks like the thing to use to me. > > > > > > It seems to have been around only since v3.3 though, which makes it a > > > bit tricky to use when upgrading from running board-file based v3.2 > > > system (Debian Wheezy) to a newer DTB based kernel, we need to select > > > the new DTB while running the old system. > > > > > > I'd prefer to use this thing as the primary mechanism but it seems like > > > I'd have to implement some sort of fallback at least for one Debian > > > release cycle. I'm sure it is doable... > > > > back in v3.2, lspci should still work. Would that given you the > > information you need? > > I expect it will, yes. 3.14 with the new PCIe driver will also work. The patch was accepted and considered a regression so made it into one of the -rc's. Andrew
On Mon, 2014-02-24 at 17:24 +0100, Andrew Lunn wrote: > > > > > What's wrong with the soc subsystem (drivers/base/soc.c). This > > > > > provides a way to export SoC through standardised interfaces. > > > > > > > > It looks like the thing to use to me. > > > > > > > > It seems to have been around only since v3.3 though, which makes it a > > > > bit tricky to use when upgrading from running board-file based v3.2 > > > > system (Debian Wheezy) to a newer DTB based kernel, we need to select > > > > the new DTB while running the old system. > > > > > > > > I'd prefer to use this thing as the primary mechanism but it seems like > > > > I'd have to implement some sort of fallback at least for one Debian > > > > release cycle. I'm sure it is doable... > > > > > > back in v3.2, lspci should still work. Would that given you the > > > information you need? > > > > I expect it will, yes. > > 3.14 with the new PCIe driver will also work. The patch was accepted > and considered a regression so made it into one of the -rc's. Great! Thanks. Ian.
On Mon, Feb 24, 2014 at 04:26:16PM +0000, Ian Campbell wrote: > On Mon, 2014-02-24 at 17:24 +0100, Andrew Lunn wrote: > > > > > > What's wrong with the soc subsystem (drivers/base/soc.c). This > > > > > > provides a way to export SoC through standardised interfaces. > > > > > > > > > > It looks like the thing to use to me. > > > > > > > > > > It seems to have been around only since v3.3 though, which makes it a > > > > > bit tricky to use when upgrading from running board-file based v3.2 > > > > > system (Debian Wheezy) to a newer DTB based kernel, we need to select > > > > > the new DTB while running the old system. > > > > > > > > > > I'd prefer to use this thing as the primary mechanism but it seems like > > > > > I'd have to implement some sort of fallback at least for one Debian > > > > > release cycle. I'm sure it is doable... > > > > > > > > back in v3.2, lspci should still work. Would that given you the > > > > information you need? > > > > > > I expect it will, yes. > > > > 3.14 with the new PCIe driver will also work. The patch was accepted > > and considered a regression so made it into one of the -rc's. > > Great! Thanks. fyi: 322a8e91844f PCI: mvebu: Use Device ID and revision from underlying endpoint It's in -rc4 and it's flagged for stable from v3.11 on up. v3.11 is when the pcie driver was introduced (and thus, the regression). hth, Jason.
On Mon, 2014-02-24 at 16:03 +0000, Ian Campbell wrote: > On Fri, 2014-02-21 at 02:00 +0000, Ben Hutchings wrote: > > On Thu, 2014-02-20 at 14:24 +0000, Ian Campbell wrote: > > > On Thu, 2014-02-20 at 14:23 +0100, Andrew Lunn wrote: > > [...] > > > > What i suspect we will end up doing it dropping the last patch for the > > > > moment and ensuring ARCH_KIRKWOOD still supports all the DT machines. > > > > I think that just needs care with arch/arm/boot/dts/Makefile. > > > > > > > > Once we have the last four converted over to DT, you can then do a > > > > straight swap, mach-kirkwood for mach-mvebu. > > > > > > That sounds like a good plan, thanks! > > > > > > If we are going to do a straight swap I suppose it might as go for a v5 > > > multiplatform flavour instead of a mvebu specific one. > > [...] > > > > I would love it if we could do that. > > > > By the way, we still have the problem that at least one supported > > orion5x machine (D-Link DNS-323) only has a ~1.5 MB kernel partition. > > So we would probably have to keep a reduced orion5x config for those > > machines, alongside the mvebu or multiplatform kernel. > > Sure. I think at worst we should aim to end up with as many flavour as > we have today, in reality I expect we should be able to end up with > fewer (even if only -= 1). > > BTW, someone (I forget who) at Debconf in Cambridge last year floated > the idea of putting a stage 2 loader in flash to pull the real kernel > from some larger storage. I don't know if that is realistic here, and in > any case I don't intend to work on it myself. I do remember that, and I like it. But in order to rely on this, I think we would need to provide a mostly automatic and safe upgrade path in Debian. Unless someone is prepared to spend the (possibly substantial) effort to do that, we're stuck with that limitation. Ben.
On Sunday 23 February 2014, Simon Guinot wrote: > I am quite busy this days but as soon I get some free time I will take > care of the DT conversion for the Lacie boards. > > Basically, we need to fix some minor issues with the Thomas patches: > > ARM: kirkwood: convert d2net_v2 to DT > ARM: kirkwood: convert LaCie Net{2, 5}Big v2 platforms to DT > > And also a DT binding must be added to the LED driver leds-netxbig. I just took a brief look at the LED driver. I think it would be reasonable to move almost all of the platform_data into the driver itself and associate the two versions with distinct "compatible" strings. That works in this particular case because while the driver is generic enough to handle other cases, I also wouldn't expect it to ever get used again on another platform. The main change to the driver would be to add support for a binding that gets the seven gpio numbers out of the DT then. Arnd
On Tue, Feb 25, 2014 at 01:44:23PM +0100, Arnd Bergmann wrote: > On Sunday 23 February 2014, Simon Guinot wrote: > > I am quite busy this days but as soon I get some free time I will take > > care of the DT conversion for the Lacie boards. > > > > Basically, we need to fix some minor issues with the Thomas patches: > > > > ARM: kirkwood: convert d2net_v2 to DT > > ARM: kirkwood: convert LaCie Net{2, 5}Big v2 platforms to DT > > > > And also a DT binding must be added to the LED driver leds-netxbig. > > I just took a brief look at the LED driver. I think it would be > reasonable to move almost all of the platform_data into the driver > itself and associate the two versions with distinct "compatible" > strings. That works in this particular case because while the driver > is generic enough to handle other cases, I also wouldn't expect > it to ever get used again on another platform. Actually, this driver is also used by the Atom-based LaCie NASes. Mainline support for this platforms should be provided soon. > > The main change to the driver would be to add support for a binding > that gets the seven gpio numbers out of the DT then. Unfortunately not, we have to pass the whole thing through DT. Simon
On Tue, Feb 25, 2014 at 04:36:14PM +0100, Arnd Bergmann wrote: > On Tuesday 25 February 2014, Simon Guinot wrote: > > On Tue, Feb 25, 2014 at 01:44:23PM +0100, Arnd Bergmann wrote: > > > On Sunday 23 February 2014, Simon Guinot wrote: > > > > I am quite busy this days but as soon I get some free time I will take > > > > care of the DT conversion for the Lacie boards. > > > > > > > > Basically, we need to fix some minor issues with the Thomas patches: > > > > > > > > ARM: kirkwood: convert d2net_v2 to DT > > > > ARM: kirkwood: convert LaCie Net{2, 5}Big v2 platforms to DT > > > > > > > > And also a DT binding must be added to the LED driver leds-netxbig. > > > > > > I just took a brief look at the LED driver. I think it would be > > > reasonable to move almost all of the platform_data into the driver > > > itself and associate the two versions with distinct "compatible" > > > strings. That works in this particular case because while the driver > > > is generic enough to handle other cases, I also wouldn't expect > > > it to ever get used again on another platform. > > > > Actually, this driver is also used by the Atom-based LaCie NASes. > > Mainline support for this platforms should be provided soon. > > Do you use DT for those machines as well, or how do you get the > data into the driver there? We are using the old fashion platform_device mechanism. The resources are defined in some board-setup files stored in the arch/x86/platform repository. > > > > The main change to the driver would be to add support for a binding > > > that gets the seven gpio numbers out of the DT then. > > > > Unfortunately not, we have to pass the whole thing through DT. > > Ok :( Yes, it is pain in the ass :( Simon
On Tuesday 25 February 2014, Simon Guinot wrote: > On Tue, Feb 25, 2014 at 01:44:23PM +0100, Arnd Bergmann wrote: > > On Sunday 23 February 2014, Simon Guinot wrote: > > > I am quite busy this days but as soon I get some free time I will take > > > care of the DT conversion for the Lacie boards. > > > > > > Basically, we need to fix some minor issues with the Thomas patches: > > > > > > ARM: kirkwood: convert d2net_v2 to DT > > > ARM: kirkwood: convert LaCie Net{2, 5}Big v2 platforms to DT > > > > > > And also a DT binding must be added to the LED driver leds-netxbig. > > > > I just took a brief look at the LED driver. I think it would be > > reasonable to move almost all of the platform_data into the driver > > itself and associate the two versions with distinct "compatible" > > strings. That works in this particular case because while the driver > > is generic enough to handle other cases, I also wouldn't expect > > it to ever get used again on another platform. > > Actually, this driver is also used by the Atom-based LaCie NASes. > Mainline support for this platforms should be provided soon. Do you use DT for those machines as well, or how do you get the data into the driver there? > > The main change to the driver would be to add support for a binding > > that gets the seven gpio numbers out of the DT then. > > Unfortunately not, we have to pass the whole thing through DT. Ok :( Arnd
On Tuesday 25 February 2014 16:09:44 Simon Guinot wrote: > On Tue, Feb 25, 2014 at 04:36:14PM +0100, Arnd Bergmann wrote: > > On Tuesday 25 February 2014, Simon Guinot wrote: > > > On Tue, Feb 25, 2014 at 01:44:23PM +0100, Arnd Bergmann wrote: > > > > I just took a brief look at the LED driver. I think it would be > > > > reasonable to move almost all of the platform_data into the driver > > > > itself and associate the two versions with distinct "compatible" > > > > strings. That works in this particular case because while the driver > > > > is generic enough to handle other cases, I also wouldn't expect > > > > it to ever get used again on another platform. > > > > > > Actually, this driver is also used by the Atom-based LaCie NASes. > > > Mainline support for this platforms should be provided soon. > > > > Do you use DT for those machines as well, or how do you get the > > data into the driver there? > > We are using the old fashion platform_device mechanism. The resources > are defined in some board-setup files stored in the arch/x86/platform > repository. Then better be quick, before the x86 maintainers figure out what kind of mess they are getting into, if they want to support lots of embedded machines in the future. ;-) Arnd
On Mon, 2014-02-24 at 17:24 +0100, Andrew Lunn wrote: > > > back in v3.2, lspci should still work. Would that given you the > > > information you need? > > > > I expect it will, yes. > > 3.14 with the new PCIe driver will also work. The patch was accepted > and considered a regression so made it into one of the -rc's. I've finally gotten around to doing something about detecting the various different ts-xxx platforms in order to select between the 6281 and 6282 dtbs (reminder: I need to do this when running both old board file kernels and new dtb based ones in order to support upgrades). On TS-419 the PCI ID method works fine when running under 3.2 and 3.14 both using a board file. I'm currently building 3.15 with dts support so I can test that too (and the soc subsystem export of the SoC ID which was added in 3.15) but I'm relatively confident that'll all be OK. However on my 6281 based TS-219 system there seems to be no visible PCI bus when running the 3.2 kernel in the current Debian stable release (which of course uses board support). Some info: $ grep ^Hardw /proc/cpuinfo Hardware : QNAP TS-119/TS-219 $ cat /proc/device-tree/model ; echo cat: /proc/device-tree/model: No such file or directory $ lspci $ ls /sys/bus/pci/devices/ $ ls /sys/class/pci_bus/ 0000:00@ $ dmesg | grep -i pci [ 5.024108] Kirkwood PCIe port 0: [ 5.024126] Kirkwood PCIe port 1: [ 5.024143] PCI: bus0 uses PCIe port 1 [ 5.024342] PCI: bus0: Fast back to back transfers enabled [ 5.048486] PCI: CLS 0 bytes, default 32 $ dmesg | grep 628 [ 5.022263] Kirkwood: MV88F6281-A1, TCLK=200000000. ts219-setup.c and ts41x-setup.c don't appear to differ meaningfully in their pcie setup -- i.e. they both call kirkwood_pcie_init, so I suppose the difference is whether there is anything on the bus or not. Is the lack of anything on the PCI bus itself sufficient to determine that this is a 6281 based ts219 rather than a 6282 one (I don't have any 6282 ts219 systems to try)? Might PHYAD (reported by ethtool eth0) be a useful fallback mechanism? AIUI the phy addr is 8 for 6281 systems and 0 for 6282 ones. Any other ideas? Also the ts219-setup.c board file supports the ts119 as well, but I don't see a DTB for that, is that in the works? Any ideas how I can distinguish a 219 from a 119? On the 219 /sys/class/pci_bus/0000:00 exists (there is nothing under /sys/bus/pci/devices/ though), and since the main difference in ts219-setup.c is that 119 doesn't call kirkwood_pcie_init() I suspect the presence or absence of /sys/class/pci_bus/0000:00 might be sufficient to distinguish them, does that sound likely? (I don't have a ts119 to try either). Thanks for any advice. Ian.
> However on my 6281 based TS-219 system there seems to be no visible PCI > bus when running the 3.2 kernel in the current Debian stable release > (which of course uses board support). Some info: The old PCI driver looks to see if there is anything on the bus, and if not, does not register the PCI bus to the PCI core. The new PCI driver always registers the busses, allowing hotplug of PCI devices. > Is the lack of anything on the PCI bus itself sufficient to determine > that this is a 6281 based ts219 rather than a 6282 one (I don't have any > 6282 ts219 systems to try)? No, this is not sufficient, as far as i know. I have a 6282 based ts119. It also does not have any PCI devices. However, the 6282 DT file works fine on it. There is no need to differentiate between 119 and 219, just between 6281 and 6282. Your idea about Ethernet PHY is probably the best way to tell them apart. But i will see if i can find anything else. Andrew
On Sat, 2014-05-03 at 16:40 +0200, Andrew Lunn wrote: > > However on my 6281 based TS-219 system there seems to be no visible PCI > > bus when running the 3.2 kernel in the current Debian stable release > > (which of course uses board support). Some info: > > The old PCI driver looks to see if there is anything on the bus, and > if not, does not register the PCI bus to the PCI core. The new PCI > driver always registers the busses, allowing hotplug of PCI devices. Got it, thanks. > > Is the lack of anything on the PCI bus itself sufficient to determine > > that this is a 6281 based ts219 rather than a 6282 one (I don't have any > > 6282 ts219 systems to try)? > > No, this is not sufficient, as far as i know. I have a 6282 based > ts119. It also does not have any PCI devices. However, the 6282 DT > file works fine on it. There is no need to differentiate between 119 > and 219, just between 6281 and 6282. Thanks. > Your idea about Ethernet PHY is probably the best way to tell them > apart. But i will see if i can find anything else. Thanks, I'll start on the PHY base solution, it'll be easy enough to switch if something even better gets thought up. Cheers, Ian.
diff --git a/arch/arm/configs/kirkwood_defconfig b/arch/arm/configs/kirkwood_defconfig index 2e762d94e94b..95b5585c1fbb 100644 --- a/arch/arm/configs/kirkwood_defconfig +++ b/arch/arm/configs/kirkwood_defconfig @@ -20,13 +20,9 @@ CONFIG_MACH_RD88F6281=y CONFIG_MACH_T5325=y CONFIG_MACH_TS219=y CONFIG_MACH_TS41X=y -CONFIG_ARCH_KIRKWOOD_DT=y -CONFIG_MACH_MV88F6281GTW_GE_DT=y # CONFIG_CPU_FEROCEON_OLD_ID is not set -CONFIG_PCI_MVEBU=y CONFIG_PREEMPT=y CONFIG_AEABI=y -# CONFIG_OABI_COMPAT is not set CONFIG_HIGHMEM=y CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 @@ -85,7 +81,6 @@ CONFIG_LEGACY_PTY_COUNT=16 CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_RUNTIME_UARTS=2 -CONFIG_SERIAL_OF_PLATFORM=y # CONFIG_HW_RANDOM is not set CONFIG_I2C=y # CONFIG_I2C_COMPAT is not set @@ -176,5 +171,4 @@ CONFIG_CRYPTO_PCBC=m # CONFIG_CRYPTO_ANSI_CPRNG is not set CONFIG_CRYPTO_DEV_MV_CESA=y CONFIG_CRC_CCITT=y -CONFIG_CRC16=y CONFIG_LIBCRC32C=y diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig index df4b26340ae4..fb4560d2605f 100644 --- a/arch/arm/mach-kirkwood/Kconfig +++ b/arch/arm/mach-kirkwood/Kconfig @@ -88,24 +88,6 @@ config MACH_TS41X QNAP TS-410, TS-410U, TS-419P, TS-419P+ and TS-419U Turbo NAS devices. -comment "Device tree entries" - -config ARCH_KIRKWOOD_DT - bool "Marvell Kirkwood Flattened Device Tree" - select KIRKWOOD_CLK - select OF_IRQ - select ORION_IRQCHIP - select ORION_TIMER - select POWER_SUPPLY - select POWER_RESET - select POWER_RESET_GPIO - select REGULATOR - select REGULATOR_FIXED_VOLTAGE - select USE_OF - help - Say 'Y' here if you want your kernel to support the - Marvell Kirkwood using flattened device tree. - endmenu endif diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile index 3a72c5c6e747..c772d7584937 100644 --- a/arch/arm/mach-kirkwood/Makefile +++ b/arch/arm/mach-kirkwood/Makefile @@ -10,5 +10,3 @@ obj-$(CONFIG_MACH_RD88F6281) += rd88f6281-setup.o obj-$(CONFIG_MACH_T5325) += t5325-setup.o obj-$(CONFIG_MACH_TS219) += ts219-setup.o tsx1x-common.o obj-$(CONFIG_MACH_TS41X) += ts41x-setup.o tsx1x-common.o - -obj-$(CONFIG_ARCH_KIRKWOOD_DT) += board-dt.o diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c deleted file mode 100644 index 2ef59ee2182d..000000000000 --- a/arch/arm/mach-kirkwood/board-dt.c +++ /dev/null @@ -1,227 +0,0 @@ -/* - * Copyright 2012 (C), Jason Cooper <jason@lakedaemon.net> - * - * arch/arm/mach-kirkwood/board-dt.c - * - * Flattened Device Tree board initialization - * - * This file is licensed under the terms of the GNU General Public - * License version 2. This program is licensed "as is" without any - * warranty of any kind, whether express or implied. - */ - -#include <linux/clk.h> -#include <linux/kernel.h> -#include <linux/init.h> -#include <linux/of.h> -#include <linux/of_address.h> -#include <linux/of_net.h> -#include <linux/of_platform.h> -#include <linux/dma-mapping.h> -#include <linux/irqchip.h> -#include <linux/kexec.h> -#include <asm/hardware/cache-feroceon-l2.h> -#include <asm/mach/arch.h> -#include <asm/mach/map.h> -#include <mach/bridge-regs.h> -#include <plat/common.h> -#include <plat/pcie.h> -#include "pm.h" - -static struct map_desc kirkwood_io_desc[] __initdata = { - { - .virtual = (unsigned long) KIRKWOOD_REGS_VIRT_BASE, - .pfn = __phys_to_pfn(KIRKWOOD_REGS_PHYS_BASE), - .length = KIRKWOOD_REGS_SIZE, - .type = MT_DEVICE, - }, -}; - -static void __init kirkwood_map_io(void) -{ - iotable_init(kirkwood_io_desc, ARRAY_SIZE(kirkwood_io_desc)); -} - -static struct resource kirkwood_cpufreq_resources[] = { - [0] = { - .start = CPU_CONTROL_PHYS, - .end = CPU_CONTROL_PHYS + 3, - .flags = IORESOURCE_MEM, - }, -}; - -static struct platform_device kirkwood_cpufreq_device = { - .name = "kirkwood-cpufreq", - .id = -1, - .num_resources = ARRAY_SIZE(kirkwood_cpufreq_resources), - .resource = kirkwood_cpufreq_resources, -}; - -static void __init kirkwood_cpufreq_init(void) -{ - platform_device_register(&kirkwood_cpufreq_device); -} - -static struct resource kirkwood_cpuidle_resource[] = { - { - .flags = IORESOURCE_MEM, - .start = DDR_OPERATION_BASE, - .end = DDR_OPERATION_BASE + 3, - }, -}; - -static struct platform_device kirkwood_cpuidle = { - .name = "kirkwood_cpuidle", - .id = -1, - .resource = kirkwood_cpuidle_resource, - .num_resources = 1, -}; - -static void __init kirkwood_cpuidle_init(void) -{ - platform_device_register(&kirkwood_cpuidle); -} - -/* Temporary here since mach-mvebu has a function we can use */ -static void kirkwood_restart(enum reboot_mode mode, const char *cmd) -{ - /* - * Enable soft reset to assert RSTOUTn. - */ - writel(SOFT_RESET_OUT_EN, RSTOUTn_MASK); - - /* - * Assert soft reset. - */ - writel(SOFT_RESET, SYSTEM_SOFT_RESET); - - while (1) - ; -} - -#define MV643XX_ETH_MAC_ADDR_LOW 0x0414 -#define MV643XX_ETH_MAC_ADDR_HIGH 0x0418 - -static void __init kirkwood_dt_eth_fixup(void) -{ - struct device_node *np; - - /* - * The ethernet interfaces forget the MAC address assigned by u-boot - * if the clocks are turned off. Usually, u-boot on kirkwood boards - * has no DT support to properly set local-mac-address property. - * As a workaround, we get the MAC address from mv643xx_eth registers - * and update the port device node if no valid MAC address is set. - */ - for_each_compatible_node(np, NULL, "marvell,kirkwood-eth-port") { - struct device_node *pnp = of_get_parent(np); - struct clk *clk; - struct property *pmac; - void __iomem *io; - u8 *macaddr; - u32 reg; - - if (!pnp) - continue; - - /* skip disabled nodes or nodes with valid MAC address*/ - if (!of_device_is_available(pnp) || of_get_mac_address(np)) - goto eth_fixup_skip; - - clk = of_clk_get(pnp, 0); - if (IS_ERR(clk)) - goto eth_fixup_skip; - - io = of_iomap(pnp, 0); - if (!io) - goto eth_fixup_no_map; - - /* ensure port clock is not gated to not hang CPU */ - clk_prepare_enable(clk); - - /* store MAC address register contents in local-mac-address */ - pr_err(FW_INFO "%s: local-mac-address is not set\n", - np->full_name); - - pmac = kzalloc(sizeof(*pmac) + 6, GFP_KERNEL); - if (!pmac) - goto eth_fixup_no_mem; - - pmac->value = pmac + 1; - pmac->length = 6; - pmac->name = kstrdup("local-mac-address", GFP_KERNEL); - if (!pmac->name) { - kfree(pmac); - goto eth_fixup_no_mem; - } - - macaddr = pmac->value; - reg = readl(io + MV643XX_ETH_MAC_ADDR_HIGH); - macaddr[0] = (reg >> 24) & 0xff; - macaddr[1] = (reg >> 16) & 0xff; - macaddr[2] = (reg >> 8) & 0xff; - macaddr[3] = reg & 0xff; - - reg = readl(io + MV643XX_ETH_MAC_ADDR_LOW); - macaddr[4] = (reg >> 8) & 0xff; - macaddr[5] = reg & 0xff; - - of_update_property(np, pmac); - -eth_fixup_no_mem: - iounmap(io); - clk_disable_unprepare(clk); -eth_fixup_no_map: - clk_put(clk); -eth_fixup_skip: - of_node_put(pnp); - } -} - -/* - * Disable propagation of mbus errors to the CPU local bus, as this - * causes mbus errors (which can occur for example for PCI aborts) to - * throw CPU aborts, which we're not set up to deal with. - */ -void kirkwood_disable_mbus_error_propagation(void) -{ - void __iomem *cpu_config; - - cpu_config = ioremap(CPU_CONFIG_PHYS, 4); - writel(readl(cpu_config) & ~CPU_CONFIG_ERROR_PROP, cpu_config); -} - - -static void __init kirkwood_dt_init(void) -{ - kirkwood_disable_mbus_error_propagation(); - - BUG_ON(mvebu_mbus_dt_init()); - - feroceon_of_init(); - - kirkwood_cpufreq_init(); - kirkwood_cpuidle_init(); - - kirkwood_pm_init(); - kirkwood_dt_eth_fixup(); - -#ifdef CONFIG_KEXEC - kexec_reinit = kirkwood_enable_pcie; -#endif - - of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); -} - -static const char * const kirkwood_dt_board_compat[] = { - "marvell,kirkwood", - NULL -}; - -DT_MACHINE_START(KIRKWOOD_DT, "Marvell Kirkwood (Flattened Device Tree)") - /* Maintainer: Jason Cooper <jason@lakedaemon.net> */ - .map_io = kirkwood_map_io, - .init_machine = kirkwood_dt_init, - .restart = kirkwood_restart, - .dt_compat = kirkwood_dt_board_compat, -MACHINE_END
Now that all the device tree support is in mach-mvebu, remove it from mach-kirkwood. Regenerate kirkwood_defconfig, removing all DT support, and a couple of other redundent options have been removed in the process. Signed-off-by: Andrew Lunn <andrew@lunn.ch> --- arch/arm/configs/kirkwood_defconfig | 6 - arch/arm/mach-kirkwood/Kconfig | 18 --- arch/arm/mach-kirkwood/Makefile | 2 - arch/arm/mach-kirkwood/board-dt.c | 227 ------------------------------------ 4 files changed, 253 deletions(-) delete mode 100644 arch/arm/mach-kirkwood/board-dt.c