On Wed, 2021-03-24 at 17:22 -0400, Tom Rini wrote: > On Wed, Mar 24, 2021 at 09:11:01PM +0000, Harm Berntsen wrote: > > On Thu, 2021-02-11 at 15:06 -0500, Tom Rini wrote: > > > On Wed, Feb 10, 2021 at 09:09:56PM -0800, Rick Thomas wrote: > > > > > > > > > > > > On Wed, Feb 10, 2021, at 8:57 PM, Vagrant Cascadian wrote: > > > > > On 2021-02-10, Rick Thomas wrote: > > > > > > I have not recently (since before 2019) done anything more > > > > > > than > > > > > > allow > > > > > > aptitude to upgrade packages as it thinks best. In > > > > > > particular, I > > > > > > have > > > > > > not made any attempt to burn new firmware on the device. > > > > > > > > > > The debian u-boot packages do not automatically upgrade the > > > > > u-boot > > > > > installed to the device; it requires manual intervention on > > > > > the > > > > > part of > > > > > the system administrator above and beyond just upgrading the > > > > > debian > > > > > packages through apt, aptitude, etc. > > > > > > > > > > I think u-boot upstream is talking about dropping it for > > > > > 2021.04, > > > > > so my > > > > > guess is you would still have another entire debian release > > > > > cycle > > > > > with > > > > > the available 2021.01 version of u-boot *if* that version > > > > > still > > > > > works... > > > > > > > > If you can point me to instructions for doing that manual > > > > intervention, I'll be happy to test whatever version you > > > > recommend, > > > > I > > > > hope the instructions also include how to recover if it > > > > *doesn't* > > > > work! > > > > > > I think this unfortunately gets to the heart of the problem. We > > > need > > > someone that cares about the platform to step up and do the > > > maintenance. > > > Most of the work shouldn't be too hard and there's examples of > > > many > > > previous conversions. The mvsata_ide driver is probably the > > > hardest > > > part but I think it just means that the ide_preinit() call needs > > > to be > > > worked in to the new ide_probe() function rather than the old > > > ide_init(). > > > > > > > I have just converted the MMC driver (mmc_mvebu) to the driver > > model > > and that works on my Kirkwood based board (not a sheevaplug > > though). > > I'll run it through my GitLab CI and submit it to the mailing list > > soon. > > > > Would MMC support be enough to keep this board in U-Boot? If I > > understand Tom correctly the only non-DM driver is the IDE driver. > > Would it be an option to keep the Sheevaplug board without IDE > > support > > (unless someone submits a driver)? I do not own a Sheevaplug and > > thus I > > am not familiar with it. I suppose it could also boot from MMC. > > I would really like to see someone be active in maintaining the > sheevaplug, especially given how popular it was among enthusiasts. > But > yes, if MMC is converted that does mean there's a viable path to keep > using a modern U-Boot on the system and I'll just rip out the IDE > driver > until someone wants to convert that and test it. USB will also need > to > be converted soon too as I will start pulling out v2019.07 deadline > items for after v2021.07 release and that's both the IDE and USB > drivers. But maybe both can be easily disabled. >
Great :). The sheevaplug currently already has driver-model based USB drivers in its defconfig. I just checked and confirmed that that driver still works on my (non-sheevaplug) Kirkwood board.