Hi Linus and maintainers,
arch/sh seems pretty much unmaintained these days. The last time I got
any reply to sh patches from the list maintainers, and the last maintainer
pull request was over a year ago, and even that has been rather sporadic.
In the meantime we've not really seen any updates for new kernel features
and code seems to be bitrotting.
Hi Christoph!
On 6/25/19 10:56 AM, Christoph Hellwig wrote:
> arch/sh seems pretty much unmaintained these days. The last time I got
> any reply to sh patches from the list maintainers, and the last maintainer
> pull request was over a year ago, and even that has been rather sporadic.
>
> In the meantime we've not really seen any updates for new kernel features
> and code seems to be bitrotting.
We're still using sh4 in Debian and most of the stuff works fine. There is
one patch by Michael Karcher that fixes a bug in the kprobes code that someone
should pull in as it unbreaks the kernel with kprobes enabled [1].
Yoshinori Sato is still active sporadically and has a kernel tree here
where he collects patches for -next [2].
Otherwise, the kernel works fine.
Adrian
> [1] https://marc.info/?l=linux-sh&m=156034655921917&w=2
> [2] https://osdn.net/projects/uclinux-h8/scm/git/linux/
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Tue, Jun 25, 2019 at 11:02:36AM +0200, John Paul Adrian Glaubitz wrote:
> On 6/25/19 10:56 AM, Christoph Hellwig wrote:
> > arch/sh seems pretty much unmaintained these days. The last time I got
> > any reply to sh patches from the list maintainers, and the last maintainer
> > pull request was over a year ago, and even that has been rather sporadic.
> >
> > In the meantime we've not really seen any updates for new kernel features
> > and code seems to be bitrotting.
>
> We're still using sh4 in Debian
I wouldn't call it "used": it has popcon of 1, and despite watching many
Debian channels, I don't recall hearing a word about sh4 in quite a while.
Hardware development is dead: we were promised modern silicon by j-core
after original patents expired, but after J2 nothing happened, there was
silence from their side, and now https://j-core.org is down.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Packager's rule #1: upstream _always_ screws something up. This
⢿⡄⠘⠷⠚⠋⠀ is true especially if you're packaging your own project.
⠈⠳⣄⠀⠀⠀⠀
Adam,
On 6/25/19 1:21 PM, Adam Borowski wrote:
>> We're still using sh4 in Debian
>
> I wouldn't call it "used": it has popcon of 1, and despite watching many
> Debian channels, I don't recall hearing a word about sh4 in quite a while.
So, according to your logic, Debian should drop the mips64el (popcon 1)
and riscv64 ports (popcon 2) [1]?
> Hardware development is dead: we were promised modern silicon by j-core
> after original patents expired, but after J2 nothing happened, there was
> silence from their side, and now https://j-core.org is down.
It's not dead. You can still run it on an FPGA, the code is freely available.
Plus, the architecture seems to be still in use in the industry [2].
Adrian
> [1] https://popcon.debian.org/
> [2] https://marc.info/?l=linux-sh&m=155170489401832&w=2
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Tue, Jun 25, 2019 at 2:02 PM John Paul Adrian Glaubitz
<[email protected]> wrote:
>
> Adam,
>
> On 6/25/19 1:21 PM, Adam Borowski wrote:
> >> We're still using sh4 in Debian
> >
> > I wouldn't call it "used": it has popcon of 1, and despite watching many
> > Debian channels, I don't recall hearing a word about sh4 in quite a while.
>
> So, according to your logic, Debian should drop the mips64el (popcon 1)
> and riscv64 ports (popcon 2) [1]?
>
> > Hardware development is dead: we were promised modern silicon by j-core
> > after original patents expired, but after J2 nothing happened, there was
> > silence from their side, and now https://j-core.org is down.
>
> It's not dead. You can still run it on an FPGA, the code is freely available.
> Plus, the architecture seems to be still in use in the industry [2].
It would be nice if one of the maintainers or the remaining users could go
through the code though and figure out which bits are definitely dead
(e.g. sh5), don't build, or are incomplete and not worked on for a long
time, compared to the bits that are known to work and that someone
is still using or at least playing with.
I guess a lot of the SoCs that have no board support other than
the Hitachi/Renesas reference platform can go away too, as any products
based on those boards have long stopped updating their kernels.
Arnd
On Tue, Jun 25, 2019 at 10:21:44AM -0400, Rich Felker wrote:
> I'm generally okay with all proposed non-functional changes that come
> up that are just eliminating arch-specific cruft to use new shared
> kernel infrastructure. I recall replying to a few indicating this, but
> I missed a lot more. If it would be helpful I think I can commit to
> doing at least this more consistently, but I'm happy to have other
> maintainers make that call too.
It woud be great if you could at least apply with a tentative ack.
At least for some trees we try very hard to get a maintainer ack,
so silence is holding things back to some extent.
I'd also like to second Arnds request to figure out if any bits
are truely dead. E.g. 64-bit sh5 support very much appears so.
On Tue, Jun 25, 2019 at 04:23:41PM +0200, Christoph Hellwig wrote:
> On Tue, Jun 25, 2019 at 10:21:44AM -0400, Rich Felker wrote:
> > I'm generally okay with all proposed non-functional changes that come
> > up that are just eliminating arch-specific cruft to use new shared
> > kernel infrastructure. I recall replying to a few indicating this, but
> > I missed a lot more. If it would be helpful I think I can commit to
> > doing at least this more consistently, but I'm happy to have other
> > maintainers make that call too.
>
> It woud be great if you could at least apply with a tentative ack.
> At least for some trees we try very hard to get a maintainer ack,
> so silence is holding things back to some extent.
OK.
> I'd also like to second Arnds request to figure out if any bits
> are truely dead. E.g. 64-bit sh5 support very much appears so.
I agree, and just replied there.
Rich
On Tue, Jun 25, 2019 at 02:50:01PM +0200, Arnd Bergmann wrote:
> On Tue, Jun 25, 2019 at 2:02 PM John Paul Adrian Glaubitz
> <[email protected]> wrote:
> >
> > Adam,
> >
> > On 6/25/19 1:21 PM, Adam Borowski wrote:
> > >> We're still using sh4 in Debian
> > >
> > > I wouldn't call it "used": it has popcon of 1, and despite watching many
> > > Debian channels, I don't recall hearing a word about sh4 in quite a while.
> >
> > So, according to your logic, Debian should drop the mips64el (popcon 1)
> > and riscv64 ports (popcon 2) [1]?
> >
> > > Hardware development is dead: we were promised modern silicon by j-core
> > > after original patents expired, but after J2 nothing happened, there was
> > > silence from their side, and now https://j-core.org is down.
> >
> > It's not dead. You can still run it on an FPGA, the code is freely available.
> > Plus, the architecture seems to be still in use in the industry [2].
>
> It would be nice if one of the maintainers or the remaining users could go
> through the code though and figure out which bits are definitely dead
> (e.g. sh5),
I'm in favor of removing sh5 (64-bit). It's already been removed from
GCC and as I understand there was never any hardware really available.
There's also a lot of NUMA-type infrastructure in arch/sh that looks
like YAGNI violations -- no clear indication that there is or ever was
any hardware it made sense on. That could probably be removed too.
> don't build, or are incomplete and not worked on for a long
> time, compared to the bits that are known to work and that someone
> is still using or at least playing with.
> I guess a lot of the SoCs that have no board support other than
> the Hitachi/Renesas reference platform can go away too, as any products
> based on those boards have long stopped updating their kernels.
My intent here was always, after getting device tree theoretically
working for some reasonable subset of socs/boards, drop the rest and
add them back as dts files (possibly plus some small drivers) only if
there's demand/complaint about regression.
Rich
Hi Rich and Sato-san!
On 6/25/19 4:29 PM, Rich Felker wrote:
> On Tue, Jun 25, 2019 at 04:23:41PM +0200, Christoph Hellwig wrote:
>> On Tue, Jun 25, 2019 at 10:21:44AM -0400, Rich Felker wrote:
>>> I'm generally okay with all proposed non-functional changes that come
>>> up that are just eliminating arch-specific cruft to use new shared
>>> kernel infrastructure. I recall replying to a few indicating this, but
>>> I missed a lot more. If it would be helpful I think I can commit to
>>> doing at least this more consistently, but I'm happy to have other
>>> maintainers make that call too.
>>
>> It woud be great if you could at least apply with a tentative ack.
>> At least for some trees we try very hard to get a maintainer ack,
>> so silence is holding things back to some extent.
>
> OK.
Could either of you review this patch by Michael Karcher which unbreaks
the SH kernel when kprobes are enabled [1]?
Sorry for being persistent, but the fix is actually needed to get the
Debian kernel boot on qemu-sh4 again since Debian enables kprobes.
Thanks a lot!
Adrian
> [1] https://marc.info/?l=linux-sh&m=156034655921917&w=2
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Tue, Jun 25, 2019 at 11:02:36AM +0200, John Paul Adrian Glaubitz wrote:
> Hi Christoph!
>
> On 6/25/19 10:56 AM, Christoph Hellwig wrote:
> > arch/sh seems pretty much unmaintained these days. The last time I got
> > any reply to sh patches from the list maintainers, and the last maintainer
> > pull request was over a year ago, and even that has been rather sporadic.
> >
> > In the meantime we've not really seen any updates for new kernel features
> > and code seems to be bitrotting.
>
> We're still using sh4 in Debian and most of the stuff works fine. There is
> one patch by Michael Karcher that fixes a bug in the kprobes code that someone
> should pull in as it unbreaks the kernel with kprobes enabled [1].
>
> Yoshinori Sato is still active sporadically and has a kernel tree here
> where he collects patches for -next [2].
>
> Otherwise, the kernel works fine.
Seconded. I apologize that I haven't been active in maintaining the
tree as well; funding for time working on it dried up quite a while
back and I'm stretched rather thin.
I'm generally okay with all proposed non-functional changes that come
up that are just eliminating arch-specific cruft to use new shared
kernel infrastructure. I recall replying to a few indicating this, but
I missed a lot more. If it would be helpful I think I can commit to
doing at least this more consistently, but I'm happy to have other
maintainers make that call too.
I do still have WIP forward-ports of Yoshinori Sato's device tree
patches from attempts to get them working on Landisk; they're sitting
in my working tree, but the PCI stuff isn't working, probably due to
changes out from under it. I'd like to work together on getting that
fixed to unblock me on something I'm interested in getting working on
my own time, but we've never managed to sync up on it.
As Adrian probably remembers, there's also the forked-tree, bitrotted
STlinux stuff I want to get merged back into mainline based on device
tree once it's there (doing it now doesn't make sense, as it would
just add a ton more board-file cruft where it's slated for removal).
This would improve the future viability of the arch/platform since,
currently, I think ST's chips are the main SH ones you can find/get --
for example in the nextvod devices.
Rich
On Tue, Jun 25, 2019 at 4:28 PM Rich Felker <[email protected]> wrote:
> On Tue, Jun 25, 2019 at 02:50:01PM +0200, Arnd Bergmann wrote:
> > don't build, or are incomplete and not worked on for a long
> > time, compared to the bits that are known to work and that someone
> > is still using or at least playing with.
> > I guess a lot of the SoCs that have no board support other than
> > the Hitachi/Renesas reference platform can go away too, as any products
> > based on those boards have long stopped updating their kernels.
>
> My intent here was always, after getting device tree theoretically
> working for some reasonable subset of socs/boards, drop the rest and
> add them back as dts files (possibly plus some small drivers) only if
> there's demand/complaint about regression.
Do you still think that this is a likely scenario for the future though?
If nobody's actively working on the DT support for the old chips and
this is unlikely to change soon, removing the known-broken bits earlier
should at least make it easier to keep maintaining the working bits
afterwards.
FWIW, I went through the SH2, SH2A and SH3 based boards that
are supported in the kernel and found almost all of them to
be just reference platforms, with no actual product ever merged.
IIRC the idea back then was that users would supply their
own board files as an add-on patch, but I would consider all the
ones that did to be obsolete now.
HP Jornada 6xx is the main machine that was once supported, but
given that according to the defconfig file it only comes with 4MB
of RAM, it is unlikely to still boot any 5.x kernel, let alone user
space (wikipedia claims there were models with 16MB of RAM,
but that is still not a lot these days).
"Magicpanel" was another product that is supported in theory, but
the google search showed the 2007 patch for the required
flash storage driver that was never merged.
Maybe everything but J2 and SH4(a) can just get retired?
Arnd
On Wed, 26 Jun 2019 00:48:09 +0900,
Arnd Bergmann wrote:
>
> On Tue, Jun 25, 2019 at 4:28 PM Rich Felker <[email protected]> wrote:
> > On Tue, Jun 25, 2019 at 02:50:01PM +0200, Arnd Bergmann wrote:
> > > don't build, or are incomplete and not worked on for a long
> > > time, compared to the bits that are known to work and that someone
> > > is still using or at least playing with.
> > > I guess a lot of the SoCs that have no board support other than
> > > the Hitachi/Renesas reference platform can go away too, as any products
> > > based on those boards have long stopped updating their kernels.
> >
> > My intent here was always, after getting device tree theoretically
> > working for some reasonable subset of socs/boards, drop the rest and
> > add them back as dts files (possibly plus some small drivers) only if
> > there's demand/complaint about regression.
>
> Do you still think that this is a likely scenario for the future though?
>
> If nobody's actively working on the DT support for the old chips and
> this is unlikely to change soon, removing the known-broken bits earlier
> should at least make it easier to keep maintaining the working bits
> afterwards.
>
> FWIW, I went through the SH2, SH2A and SH3 based boards that
> are supported in the kernel and found almost all of them to
> be just reference platforms, with no actual product ever merged.
> IIRC the idea back then was that users would supply their
> own board files as an add-on patch, but I would consider all the
> ones that did to be obsolete now.
>
> HP Jornada 6xx is the main machine that was once supported, but
> given that according to the defconfig file it only comes with 4MB
> of RAM, it is unlikely to still boot any 5.x kernel, let alone user
> space (wikipedia claims there were models with 16MB of RAM,
> but that is still not a lot these days).
>
> "Magicpanel" was another product that is supported in theory, but
> the google search showed the 2007 patch for the required
> flash storage driver that was never merged.
>
> Maybe everything but J2 and SH4(a) can just get retired?
>
> Arnd
I also have some boards, so it's possible to rewrite more.
I can not rewrite the target I do not have, so I think that
there is nothing but to retire.
There are too many unique parts of SH and it will be difficult
to maintain in the future.
--
Yosinori Sato
On Wed, Jun 26, 2019 at 08:25:20PM +0900, Yoshinori Sato wrote:
> On Wed, 26 Jun 2019 00:48:09 +0900,
> Arnd Bergmann wrote:
> >
> > On Tue, Jun 25, 2019 at 4:28 PM Rich Felker <[email protected]> wrote:
> > > On Tue, Jun 25, 2019 at 02:50:01PM +0200, Arnd Bergmann wrote:
> > > > don't build, or are incomplete and not worked on for a long
> > > > time, compared to the bits that are known to work and that someone
> > > > is still using or at least playing with.
> > > > I guess a lot of the SoCs that have no board support other than
> > > > the Hitachi/Renesas reference platform can go away too, as any products
> > > > based on those boards have long stopped updating their kernels.
> > >
> > > My intent here was always, after getting device tree theoretically
> > > working for some reasonable subset of socs/boards, drop the rest and
> > > add them back as dts files (possibly plus some small drivers) only if
> > > there's demand/complaint about regression.
> >
> > Do you still think that this is a likely scenario for the future though?
> >
> > If nobody's actively working on the DT support for the old chips and
> > this is unlikely to change soon, removing the known-broken bits earlier
> > should at least make it easier to keep maintaining the working bits
> > afterwards.
> >
> > FWIW, I went through the SH2, SH2A and SH3 based boards that
> > are supported in the kernel and found almost all of them to
> > be just reference platforms, with no actual product ever merged.
> > IIRC the idea back then was that users would supply their
> > own board files as an add-on patch, but I would consider all the
> > ones that did to be obsolete now.
> >
> > HP Jornada 6xx is the main machine that was once supported, but
> > given that according to the defconfig file it only comes with 4MB
> > of RAM, it is unlikely to still boot any 5.x kernel, let alone user
> > space (wikipedia claims there were models with 16MB of RAM,
> > but that is still not a lot these days).
> >
> > "Magicpanel" was another product that is supported in theory, but
> > the google search showed the 2007 patch for the required
> > flash storage driver that was never merged.
> >
> > Maybe everything but J2 and SH4(a) can just get retired?
> >
> > Arnd
>
> I also have some boards, so it's possible to rewrite more.
> I can not rewrite the target I do not have, so I think that
> there is nothing but to retire.
To clarify, are you agreeing with Arnd's suggestion to retire/remove
everything but jcore and sh4[a]?
Rich
On 6/26/19 5:38 PM, Rich Felker wrote:
>>> Maybe everything but J2 and SH4(a) can just get retired?
>>>
>>> Arnd
>>
>> I also have some boards, so it's possible to rewrite more.
>> I can not rewrite the target I do not have, so I think that
>> there is nothing but to retire.
>
> To clarify, are you agreeing with Arnd's suggestion to retire/remove
> everything but jcore and sh4[a]?
I would keep J-Core, SH3 and SH4[a]. SH5 can go in any case since there
is no hardware available and gcc has no longer support for the target
either.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Thu, 27 Jun 2019 00:38:21 +0900,
Rich Felker wrote:
>
> On Wed, Jun 26, 2019 at 08:25:20PM +0900, Yoshinori Sato wrote:
> > On Wed, 26 Jun 2019 00:48:09 +0900,
> > Arnd Bergmann wrote:
> > >
> > > On Tue, Jun 25, 2019 at 4:28 PM Rich Felker <[email protected]> wrote:
> > > > On Tue, Jun 25, 2019 at 02:50:01PM +0200, Arnd Bergmann wrote:
> > > > > don't build, or are incomplete and not worked on for a long
> > > > > time, compared to the bits that are known to work and that someone
> > > > > is still using or at least playing with.
> > > > > I guess a lot of the SoCs that have no board support other than
> > > > > the Hitachi/Renesas reference platform can go away too, as any products
> > > > > based on those boards have long stopped updating their kernels.
> > > >
> > > > My intent here was always, after getting device tree theoretically
> > > > working for some reasonable subset of socs/boards, drop the rest and
> > > > add them back as dts files (possibly plus some small drivers) only if
> > > > there's demand/complaint about regression.
> > >
> > > Do you still think that this is a likely scenario for the future though?
> > >
> > > If nobody's actively working on the DT support for the old chips and
> > > this is unlikely to change soon, removing the known-broken bits earlier
> > > should at least make it easier to keep maintaining the working bits
> > > afterwards.
> > >
> > > FWIW, I went through the SH2, SH2A and SH3 based boards that
> > > are supported in the kernel and found almost all of them to
> > > be just reference platforms, with no actual product ever merged.
> > > IIRC the idea back then was that users would supply their
> > > own board files as an add-on patch, but I would consider all the
> > > ones that did to be obsolete now.
> > >
> > > HP Jornada 6xx is the main machine that was once supported, but
> > > given that according to the defconfig file it only comes with 4MB
> > > of RAM, it is unlikely to still boot any 5.x kernel, let alone user
> > > space (wikipedia claims there were models with 16MB of RAM,
> > > but that is still not a lot these days).
> > >
> > > "Magicpanel" was another product that is supported in theory, but
> > > the google search showed the 2007 patch for the required
> > > flash storage driver that was never merged.
> > >
> > > Maybe everything but J2 and SH4(a) can just get retired?
> > >
> > > Arnd
> >
> > I also have some boards, so it's possible to rewrite more.
> > I can not rewrite the target I do not have, so I think that
> > there is nothing but to retire.
>
> To clarify, are you agreeing with Arnd's suggestion to retire/remove
> everything but jcore and sh4[a]?
>
> Rich
I have SH2/2A/3 target board.
So can mantain CPU support.
But with board support it will be difficult.
I would like to make the transition to a common framework.
I also have to fix the parts that depend on each board for migration,
so I would like to limit the target for maintenance to only those
that can be used now.
--
Yosinori Sato
On 7/5/19 3:51 PM, Yoshinori Sato wrote:
> I have SH2/2A/3 target board.
I've also got SH2/2A/3 boards ;).
> So can mantain CPU support.
> But with board support it will be difficult.
> I would like to make the transition to a common framework.
Yes, that would be great. I assume the basis will be device trees.
> I also have to fix the parts that depend on each board for migration,
> so I would like to limit the target for maintenance to only those
> that can be used now.
FWIW, could you open a pull request for Linus so that the SH fixes,
especially the kprobes fix, gets merged into Linus' tree?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Fri, Jul 05, 2019 at 10:51:55PM +0900, Yoshinori Sato wrote:
> On Thu, 27 Jun 2019 00:38:21 +0900,
> Rich Felker wrote:
> >
> > On Wed, Jun 26, 2019 at 08:25:20PM +0900, Yoshinori Sato wrote:
> > > On Wed, 26 Jun 2019 00:48:09 +0900,
> > > Arnd Bergmann wrote:
> > > >
> > > > On Tue, Jun 25, 2019 at 4:28 PM Rich Felker <[email protected]> wrote:
> > > > > On Tue, Jun 25, 2019 at 02:50:01PM +0200, Arnd Bergmann wrote:
> > > > > > don't build, or are incomplete and not worked on for a long
> > > > > > time, compared to the bits that are known to work and that someone
> > > > > > is still using or at least playing with.
> > > > > > I guess a lot of the SoCs that have no board support other than
> > > > > > the Hitachi/Renesas reference platform can go away too, as any products
> > > > > > based on those boards have long stopped updating their kernels.
> > > > >
> > > > > My intent here was always, after getting device tree theoretically
> > > > > working for some reasonable subset of socs/boards, drop the rest and
> > > > > add them back as dts files (possibly plus some small drivers) only if
> > > > > there's demand/complaint about regression.
> > > >
> > > > Do you still think that this is a likely scenario for the future though?
> > > >
> > > > If nobody's actively working on the DT support for the old chips and
> > > > this is unlikely to change soon, removing the known-broken bits earlier
> > > > should at least make it easier to keep maintaining the working bits
> > > > afterwards.
> > > >
> > > > FWIW, I went through the SH2, SH2A and SH3 based boards that
> > > > are supported in the kernel and found almost all of them to
> > > > be just reference platforms, with no actual product ever merged.
> > > > IIRC the idea back then was that users would supply their
> > > > own board files as an add-on patch, but I would consider all the
> > > > ones that did to be obsolete now.
> > > >
> > > > HP Jornada 6xx is the main machine that was once supported, but
> > > > given that according to the defconfig file it only comes with 4MB
> > > > of RAM, it is unlikely to still boot any 5.x kernel, let alone user
> > > > space (wikipedia claims there were models with 16MB of RAM,
> > > > but that is still not a lot these days).
> > > >
> > > > "Magicpanel" was another product that is supported in theory, but
> > > > the google search showed the 2007 patch for the required
> > > > flash storage driver that was never merged.
> > > >
> > > > Maybe everything but J2 and SH4(a) can just get retired?
> > > >
> > > > Arnd
> > >
> > > I also have some boards, so it's possible to rewrite more.
> > > I can not rewrite the target I do not have, so I think that
> > > there is nothing but to retire.
> >
> > To clarify, are you agreeing with Arnd's suggestion to retire/remove
> > everything but jcore and sh4[a]?
> >
> > Rich
>
> I have SH2/2A/3 target board.
> So can mantain CPU support.
> But with board support it will be difficult.
> I would like to make the transition to a common framework.
> I also have to fix the parts that depend on each board for migration,
> so I would like to limit the target for maintenance to only those
> that can be used now.
Do you still have a working version of your device tree patches that
applies to current kernel? If not, could I post the forward-ported
versions I have right now (they're not up to current kernel but newer)
for you to take a look and see what might be wrong?
Your original version with the kernel version it applied to worked,
but my forward-port one doesn't. PCI is crashing during boot with the
qemu-emulated board, so I can't get disks or network, and I eventually
got frustrated trying to fix it and set it aside.
Rich