Re: [PATCH 14/25] arm: Remove sheevaplug board
On Wed, Mar 24, 2021 at 09:54:06PM +, Harm Berntsen wrote: > On Wed, 2021-03-24 at 17:22 -0400, Tom Rini wrote: > > On Wed, Mar 24, 2021 at 09:11:01PM +, 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. Ah, I bet that means the "hard" part is that you can't have both DM_MMC/DM_USB and non-DM IDE at the same time without some build failure. So turning off IDE (and deleting the driver after) and then with the MMC conversion USB should just be switched over. -- Tom signature.asc Description: PGP signature
Re: [PATCH 14/25] arm: Remove sheevaplug board
On Wed, 2021-03-24 at 17:22 -0400, Tom Rini wrote: > On Wed, Mar 24, 2021 at 09:11:01PM +, 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.
Re: [PATCH 14/25] arm: Remove sheevaplug board
On Wed, Mar 24, 2021 at 09:11:01PM +, 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. -- Tom signature.asc Description: PGP signature
Re: [PATCH 14/25] arm: Remove sheevaplug board
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.
Re: [PATCH 14/25] arm: Remove sheevaplug board
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(). -- Tom signature.asc Description: PGP signature
Re: [PATCH 14/25] arm: Remove sheevaplug board
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! Enjoy! Rick
Re: [PATCH 14/25] arm: Remove sheevaplug board
On 2021-02-10, Rick Thomas wrote: > On Wed, Feb 10, 2021, at 5:55 PM, Tom Rini wrote: >> On Wed, Feb 10, 2021 at 05:01:47PM -0800, Rick Thomas wrote: >> > On Wed, Feb 10, 2021, at 12:15 PM, Tom Rini wrote: >> > > I assume that however you're building U-Boot the warnings that get >> > > printed about conversion deadlines having come and gone are hidden in >> > > some way or another. I definitely see some warnings in the build logs, but try to get other people to help with testing and maintaining them in Debian and for most boards there is someone listed who has offered to test new versions: https://salsa.debian.org/debian/u-boot/-/blob/master/debian/targets Unfortunately, mostly I only have evidence of boards I and a few other people have tested: https://wiki.debian.org/U-boot/Status If you use Debian and want the u-boot package to work for your favorite platform working the next release, it would be a really good time to test the packaged u-boot in Debian bullseye Real Soon Now. :) >> > I used to have my sheevaplug's serial console hooked up to a nearby >> > PC. But the PC died a year or so ago, so I don't have any way to >> > watch the messages at boot time. If I need to reboot it, I just >> > ssh to it, type "sudo shutdown -r now" and pray. It hasn't failed >> > me yet (knock wood!). If it starts to fail, I'll have to find >> > another PC to hook up the serial console to, but I figure I'll >> > cross that bridge when I come to it. >> > >> > Now, if anybody wanted me to test a new bit of software on it, I'd >> > have some incentive. >> >> To be clear, have you been updating U-Boot on the device? > > I'm not sure. If it helps, here's what aptitude thinks is installed: > > rbthomas@sheeva:~$ aptitude versions u-boot > i 2019.01+dfsg-7 stable 500 > > 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... live well, vagrant signature.asc Description: PGP signature
Re: [PATCH 14/25] arm: Remove sheevaplug board
On Wed, Feb 10, 2021, at 5:55 PM, Tom Rini wrote: > On Wed, Feb 10, 2021 at 05:01:47PM -0800, Rick Thomas wrote: > > On Wed, Feb 10, 2021, at 12:15 PM, Tom Rini wrote: > > > I assume that however you're building U-Boot the warnings that get > > > printed about conversion deadlines having come and gone are hidden in > > > some way or another. > > > > I used to have my sheevaplug's serial console hooked up to a nearby PC. > > But the PC died a year or so ago, so I don't have any way to watch the > > messages at boot time. If I need to reboot it, I just ssh to it, type > > "sudo shutdown -r now" and pray. It hasn't failed me yet (knock wood!). > > If it starts to fail, I'll have to find another PC to hook up the serial > > console to, but I figure I'll cross that bridge when I come to it. > > > > Now, if anybody wanted me to test a new bit of software on it, I'd have > > some incentive. > > To be clear, have you been updating U-Boot on the device? I'm not sure. If it helps, here's what aptitude thinks is installed: rbthomas@sheeva:~$ aptitude versions u-boot i 2019.01+dfsg-7 stable500 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. Does that help? Rick
Re: [PATCH 14/25] arm: Remove sheevaplug board
On Wed, Feb 10, 2021 at 05:01:47PM -0800, Rick Thomas wrote: > On Wed, Feb 10, 2021, at 12:15 PM, Tom Rini wrote: > > I assume that however you're building U-Boot the warnings that get > > printed about conversion deadlines having come and gone are hidden in > > some way or another. > > I used to have my sheevaplug's serial console hooked up to a nearby PC. But > the PC died a year or so ago, so I don't have any way to watch the messages > at boot time. If I need to reboot it, I just ssh to it, type "sudo shutdown > -r now" and pray. It hasn't failed me yet (knock wood!). If it starts to > fail, I'll have to find another PC to hook up the serial console to, but I > figure I'll cross that bridge when I come to it. > > Now, if anybody wanted me to test a new bit of software on it, I'd have some > incentive. To be clear, have you been updating U-Boot on the device? -- Tom signature.asc Description: PGP signature
Re: [PATCH 14/25] arm: Remove sheevaplug board
On Wed, Feb 10, 2021, at 12:15 PM, Tom Rini wrote: > I assume that however you're building U-Boot the warnings that get > printed about conversion deadlines having come and gone are hidden in > some way or another. I used to have my sheevaplug's serial console hooked up to a nearby PC. But the PC died a year or so ago, so I don't have any way to watch the messages at boot time. If I need to reboot it, I just ssh to it, type "sudo shutdown -r now" and pray. It hasn't failed me yet (knock wood!). If it starts to fail, I'll have to find another PC to hook up the serial console to, but I figure I'll cross that bridge when I come to it. Now, if anybody wanted me to test a new bit of software on it, I'd have some incentive. Enjoy! Rick
Re: [PATCH 14/25] arm: Remove sheevaplug board
On Wed, Feb 10, 2021, at 12:15 PM, Tom Rini wrote: > On Wed, Feb 10, 2021 at 12:09:06PM -0800, Rick Thomas wrote: > > > If you decide to do this, please make sure you advertise it more > > widely than just this list. > > > > I have a sheevaplug that I'd be sad to have to decommission. For the > > last decade, with never a complaint, it's been happily serving DHCP, > > DNS, and NTP to about 20 machines in my home network. I like it > > because the slightly unusual architecture makes it slightly less > > attractive as a target to the bad-guys out there. > > > > Maybe I'll replace it with a Raspberry Pi. > > I'm quite happy to keep the board, if someone will step up and maintain > it. It's had the initial conversion to DM done, but it needs a number > of others still. Almost all of the drivers it uses have been converted > already (the IDE driver being the exception). > > I assume that however you're building U-Boot the warnings that get > printed about conversion deadlines having come and gone are hidden in > some way or another. Sad to say, I don't have the skills to step up and maintain it myself. Though I'll be happy to participate in the effort as a willing (nay, eager) tester of new versions. I've got a second sheevaplug sitting on a shelf that somehow bricked itself about 5-7 years ago. I'd love to try to resurrect it, if somebody can point me to instructions for re-flashing the firmware. If I can get it running, it will be perfect for use as a testing machine. Thanks! Rick
Re: [PATCH 14/25] arm: Remove sheevaplug board
If you decide to do this, please make sure you advertise it more widely than
just this list.
I have a sheevaplug that I'd be sad to have to decommission. For the last
decade, with never a complaint, it's been happily serving DHCP, DNS, and NTP
to about 20 machines in my home network. I like it because the slightly
unusual architecture makes it slightly less attractive as a target to the
bad-guys out there.
Maybe I'll replace it with a Raspberry Pi.
Oh well: To everything there is a season...
Rick
On Tue, Feb 9, 2021, at 11:07 PM, Chris Packham wrote:
> On Wed, 10 Feb 2021, 2:07 AM Tom Rini, wrote:
>
> > This board has not been converted to CONFIG_DM_MMC by the deadline of
> > v2019.04, which is almost two years ago. In addition there are other DM
> > migrations it is also missing. Remove it.
> >
>
> We did get the odd bug report from debian for sheevaplug. They were
> reasonably popular with enthusiasts at one point. Personally I wouldn't
> miss this board but it might be worth a heads up (hence adding Vagrant C.
> to the Cc).
>
>
> > Cc: Prafulla Wadaskar
> > Signed-off-by: Tom Rini
> > ---
> > arch/arm/dts/Makefile| 3 +-
> > arch/arm/dts/kirkwood-sheevaplug-common.dtsi | 104 --
> > arch/arm/dts/kirkwood-sheevaplug.dts | 42 --
> > arch/arm/mach-kirkwood/Kconfig | 4 -
> > board/Marvell/sheevaplug/Kconfig | 12 --
> > board/Marvell/sheevaplug/MAINTAINERS | 6 -
> > board/Marvell/sheevaplug/Makefile| 7 -
> > board/Marvell/sheevaplug/kwbimage.cfg| 144 ---
> > board/Marvell/sheevaplug/sheevaplug.c| 135 -
> > board/Marvell/sheevaplug/sheevaplug.h| 24
> > configs/sheevaplug_defconfig | 55 ---
> > include/configs/sheevaplug.h | 73 --
> > 12 files changed, 1 insertion(+), 608 deletions(-)
> > delete mode 100644 arch/arm/dts/kirkwood-sheevaplug-common.dtsi
> > delete mode 100644 arch/arm/dts/kirkwood-sheevaplug.dts
> > delete mode 100644 board/Marvell/sheevaplug/Kconfig
> > delete mode 100644 board/Marvell/sheevaplug/MAINTAINERS
> > delete mode 100644 board/Marvell/sheevaplug/Makefile
> > delete mode 100644 board/Marvell/sheevaplug/kwbimage.cfg
> > delete mode 100644 board/Marvell/sheevaplug/sheevaplug.c
> > delete mode 100644 board/Marvell/sheevaplug/sheevaplug.h
> > delete mode 100644 configs/sheevaplug_defconfig
> > delete mode 100644 include/configs/sheevaplug.h
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index b8f88bca0af9..12a74ed0eb08 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -58,8 +58,7 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += \
> > kirkwood-ns2lite.dtb \
> > kirkwood-ns2max.dtb \
> > kirkwood-ns2mini.dtb \
> > - kirkwood-pogo_e02.dtb \
> > - kirkwood-sheevaplug.dtb
> > + kirkwood-pogo_e02.dtb
> >
> > dtb-$(CONFIG_MACH_S900) += \
> > bubblegum_96.dtb
> > diff --git a/arch/arm/dts/kirkwood-sheevaplug-common.dtsi
> > b/arch/arm/dts/kirkwood-sheevaplug-common.dtsi
> > deleted file mode 100644
> > index 0a698d3b7393..
> > --- a/arch/arm/dts/kirkwood-sheevaplug-common.dtsi
> > +++ /dev/null
> > @@ -1,104 +0,0 @@
> > -// SPDX-License-Identifier: GPL-2.0
> > -/*
> > - * kirkwood-sheevaplug-common.dtsi - Common parts for Sheevaplugs
> > - *
> > - * Copyright (C) 2013 Simon Baatz
> > - */
> > -
> > -#include "kirkwood.dtsi"
> > -#include "kirkwood-6281.dtsi"
> > -
> > -/ {
> > - memory {
> > - device_type = "memory";
> > - reg = <0x 0x2000>;
> > - };
> > -
> > - chosen {
> > - bootargs = "console=ttyS0,115200n8 earlyprintk";
> > - stdout-path =
> > - };
> > -
> > - ocp@f100 {
> > - pinctrl: pin-controller@1 {
> > -
> > - pmx_usb_power_enable: pmx-usb-power-enable {
> > - marvell,pins = "mpp29";
> > - marvell,function = "gpio";
> > - };
> > - pmx_led_red: pmx-led-red {
> > - marvell,pins = "mpp46";
> > - marvell,function = "gpio";
> > - };
> > - pmx_led_blue: pmx-led-blue {
> > - marvell,pins = "mpp49";
> > - marvell,function = "gpio";
> > - };
> > - pmx_sdio_cd: pmx-sdio-cd {
> > - marvell,pins = "mpp44";
> > - marvell,function = "gpio";
> > - };
> > - pmx_sdio_wp: pmx-sdio-wp {
> > - marvell,pins = "mpp47";
> > - marvell,function =
Re: [PATCH 14/25] arm: Remove sheevaplug board
On Wed, Feb 10, 2021 at 12:09:06PM -0800, Rick Thomas wrote: > If you decide to do this, please make sure you advertise it more > widely than just this list. > > I have a sheevaplug that I'd be sad to have to decommission. For the > last decade, with never a complaint, it's been happily serving DHCP, > DNS, and NTP to about 20 machines in my home network. I like it > because the slightly unusual architecture makes it slightly less > attractive as a target to the bad-guys out there. > > Maybe I'll replace it with a Raspberry Pi. I'm quite happy to keep the board, if someone will step up and maintain it. It's had the initial conversion to DM done, but it needs a number of others still. Almost all of the drivers it uses have been converted already (the IDE driver being the exception). I assume that however you're building U-Boot the warnings that get printed about conversion deadlines having come and gone are hidden in some way or another. -- Tom signature.asc Description: PGP signature
Re: [PATCH 14/25] arm: Remove sheevaplug board
On Wed, 10 Feb 2021, 2:07 AM Tom Rini, wrote:
> This board has not been converted to CONFIG_DM_MMC by the deadline of
> v2019.04, which is almost two years ago. In addition there are other DM
> migrations it is also missing. Remove it.
>
We did get the odd bug report from debian for sheevaplug. They were
reasonably popular with enthusiasts at one point. Personally I wouldn't
miss this board but it might be worth a heads up (hence adding Vagrant C.
to the Cc).
> Cc: Prafulla Wadaskar
> Signed-off-by: Tom Rini
> ---
> arch/arm/dts/Makefile| 3 +-
> arch/arm/dts/kirkwood-sheevaplug-common.dtsi | 104 --
> arch/arm/dts/kirkwood-sheevaplug.dts | 42 --
> arch/arm/mach-kirkwood/Kconfig | 4 -
> board/Marvell/sheevaplug/Kconfig | 12 --
> board/Marvell/sheevaplug/MAINTAINERS | 6 -
> board/Marvell/sheevaplug/Makefile| 7 -
> board/Marvell/sheevaplug/kwbimage.cfg| 144 ---
> board/Marvell/sheevaplug/sheevaplug.c| 135 -
> board/Marvell/sheevaplug/sheevaplug.h| 24
> configs/sheevaplug_defconfig | 55 ---
> include/configs/sheevaplug.h | 73 --
> 12 files changed, 1 insertion(+), 608 deletions(-)
> delete mode 100644 arch/arm/dts/kirkwood-sheevaplug-common.dtsi
> delete mode 100644 arch/arm/dts/kirkwood-sheevaplug.dts
> delete mode 100644 board/Marvell/sheevaplug/Kconfig
> delete mode 100644 board/Marvell/sheevaplug/MAINTAINERS
> delete mode 100644 board/Marvell/sheevaplug/Makefile
> delete mode 100644 board/Marvell/sheevaplug/kwbimage.cfg
> delete mode 100644 board/Marvell/sheevaplug/sheevaplug.c
> delete mode 100644 board/Marvell/sheevaplug/sheevaplug.h
> delete mode 100644 configs/sheevaplug_defconfig
> delete mode 100644 include/configs/sheevaplug.h
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index b8f88bca0af9..12a74ed0eb08 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -58,8 +58,7 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += \
> kirkwood-ns2lite.dtb \
> kirkwood-ns2max.dtb \
> kirkwood-ns2mini.dtb \
> - kirkwood-pogo_e02.dtb \
> - kirkwood-sheevaplug.dtb
> + kirkwood-pogo_e02.dtb
>
> dtb-$(CONFIG_MACH_S900) += \
> bubblegum_96.dtb
> diff --git a/arch/arm/dts/kirkwood-sheevaplug-common.dtsi
> b/arch/arm/dts/kirkwood-sheevaplug-common.dtsi
> deleted file mode 100644
> index 0a698d3b7393..
> --- a/arch/arm/dts/kirkwood-sheevaplug-common.dtsi
> +++ /dev/null
> @@ -1,104 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -/*
> - * kirkwood-sheevaplug-common.dtsi - Common parts for Sheevaplugs
> - *
> - * Copyright (C) 2013 Simon Baatz
> - */
> -
> -#include "kirkwood.dtsi"
> -#include "kirkwood-6281.dtsi"
> -
> -/ {
> - memory {
> - device_type = "memory";
> - reg = <0x 0x2000>;
> - };
> -
> - chosen {
> - bootargs = "console=ttyS0,115200n8 earlyprintk";
> - stdout-path =
> - };
> -
> - ocp@f100 {
> - pinctrl: pin-controller@1 {
> -
> - pmx_usb_power_enable: pmx-usb-power-enable {
> - marvell,pins = "mpp29";
> - marvell,function = "gpio";
> - };
> - pmx_led_red: pmx-led-red {
> - marvell,pins = "mpp46";
> - marvell,function = "gpio";
> - };
> - pmx_led_blue: pmx-led-blue {
> - marvell,pins = "mpp49";
> - marvell,function = "gpio";
> - };
> - pmx_sdio_cd: pmx-sdio-cd {
> - marvell,pins = "mpp44";
> - marvell,function = "gpio";
> - };
> - pmx_sdio_wp: pmx-sdio-wp {
> - marvell,pins = "mpp47";
> - marvell,function = "gpio";
> - };
> - };
> - serial@12000 {
> - status = "okay";
> - };
> - };
> -
> - regulators {
> - compatible = "simple-bus";
> - #address-cells = <1>;
> - #size-cells = <0>;
> - pinctrl-0 = <_usb_power_enable>;
> - pinctrl-names = "default";
> -
> - usb_power: regulator@1 {
> - compatible = "regulator-fixed";
> - reg = <1>;
> - regulator-name = "USB Power";
> - regulator-min-microvolt = <500>;
> - regulator-max-microvolt = <500>;
> - enable-active-high;
>
[PATCH 14/25] arm: Remove sheevaplug board
This board has not been converted to CONFIG_DM_MMC by the deadline of
v2019.04, which is almost two years ago. In addition there are other DM
migrations it is also missing. Remove it.
Cc: Prafulla Wadaskar
Signed-off-by: Tom Rini
---
arch/arm/dts/Makefile| 3 +-
arch/arm/dts/kirkwood-sheevaplug-common.dtsi | 104 --
arch/arm/dts/kirkwood-sheevaplug.dts | 42 --
arch/arm/mach-kirkwood/Kconfig | 4 -
board/Marvell/sheevaplug/Kconfig | 12 --
board/Marvell/sheevaplug/MAINTAINERS | 6 -
board/Marvell/sheevaplug/Makefile| 7 -
board/Marvell/sheevaplug/kwbimage.cfg| 144 ---
board/Marvell/sheevaplug/sheevaplug.c| 135 -
board/Marvell/sheevaplug/sheevaplug.h| 24
configs/sheevaplug_defconfig | 55 ---
include/configs/sheevaplug.h | 73 --
12 files changed, 1 insertion(+), 608 deletions(-)
delete mode 100644 arch/arm/dts/kirkwood-sheevaplug-common.dtsi
delete mode 100644 arch/arm/dts/kirkwood-sheevaplug.dts
delete mode 100644 board/Marvell/sheevaplug/Kconfig
delete mode 100644 board/Marvell/sheevaplug/MAINTAINERS
delete mode 100644 board/Marvell/sheevaplug/Makefile
delete mode 100644 board/Marvell/sheevaplug/kwbimage.cfg
delete mode 100644 board/Marvell/sheevaplug/sheevaplug.c
delete mode 100644 board/Marvell/sheevaplug/sheevaplug.h
delete mode 100644 configs/sheevaplug_defconfig
delete mode 100644 include/configs/sheevaplug.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b8f88bca0af9..12a74ed0eb08 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -58,8 +58,7 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += \
kirkwood-ns2lite.dtb \
kirkwood-ns2max.dtb \
kirkwood-ns2mini.dtb \
- kirkwood-pogo_e02.dtb \
- kirkwood-sheevaplug.dtb
+ kirkwood-pogo_e02.dtb
dtb-$(CONFIG_MACH_S900) += \
bubblegum_96.dtb
diff --git a/arch/arm/dts/kirkwood-sheevaplug-common.dtsi
b/arch/arm/dts/kirkwood-sheevaplug-common.dtsi
deleted file mode 100644
index 0a698d3b7393..
--- a/arch/arm/dts/kirkwood-sheevaplug-common.dtsi
+++ /dev/null
@@ -1,104 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * kirkwood-sheevaplug-common.dtsi - Common parts for Sheevaplugs
- *
- * Copyright (C) 2013 Simon Baatz
- */
-
-#include "kirkwood.dtsi"
-#include "kirkwood-6281.dtsi"
-
-/ {
- memory {
- device_type = "memory";
- reg = <0x 0x2000>;
- };
-
- chosen {
- bootargs = "console=ttyS0,115200n8 earlyprintk";
- stdout-path =
- };
-
- ocp@f100 {
- pinctrl: pin-controller@1 {
-
- pmx_usb_power_enable: pmx-usb-power-enable {
- marvell,pins = "mpp29";
- marvell,function = "gpio";
- };
- pmx_led_red: pmx-led-red {
- marvell,pins = "mpp46";
- marvell,function = "gpio";
- };
- pmx_led_blue: pmx-led-blue {
- marvell,pins = "mpp49";
- marvell,function = "gpio";
- };
- pmx_sdio_cd: pmx-sdio-cd {
- marvell,pins = "mpp44";
- marvell,function = "gpio";
- };
- pmx_sdio_wp: pmx-sdio-wp {
- marvell,pins = "mpp47";
- marvell,function = "gpio";
- };
- };
- serial@12000 {
- status = "okay";
- };
- };
-
- regulators {
- compatible = "simple-bus";
- #address-cells = <1>;
- #size-cells = <0>;
- pinctrl-0 = <_usb_power_enable>;
- pinctrl-names = "default";
-
- usb_power: regulator@1 {
- compatible = "regulator-fixed";
- reg = <1>;
- regulator-name = "USB Power";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- enable-active-high;
- regulator-always-on;
- regulator-boot-on;
- gpio = < 29 0>;
- };
- };
-};
-
- {
- status = "okay";
-
- partition@0 {
- label = "u-boot";
- reg = <0x000 0x10>;
- };
-
- partition@10 {
- label = "uImage";
- reg = <0x010 0x40>;
- };
-
- partition@50 {
- label = "root";
- reg =
