[PATCH 14/25] arm: Remove sheevaplug board

Harm Berntsen harm.berntsen at nedap.com
Wed Mar 24 22:54:06 CET 2021


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.


More information about the U-Boot mailing list