[fedora-arm] Who's using Kirkwood?

Dennis Gilmore dennis at ausil.us
Tue Oct 9 09:30:24 UTC 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El Tue, 9 Oct 2012 08:54:26 +0100
Peter Robinson <pbrobinson at gmail.com> escribió:
> On Mon, Oct 8, 2012 at 10:56 PM, Till Maas <opensource at till.name>
> wrote:
> > On Mon, Oct 08, 2012 at 02:53:45PM -0400, Scott Sullivan wrote:
> >> On 10/08/2012 02:35 PM, Till Maas wrote:
> >> >Hi,
> >> >
> >> >On Sat, Oct 06, 2012 at 05:43:33AM -0400, Jon Masters wrote:
> >> >
> >> >>I'm interested to know who is using Kirkwood, and who would miss
> >> >>it if it went away. For now, we won't kill off ARMv5 because it
> >> >>is used in the official rPi builds but that doesn't mean I'm not
> >> >>interested to know whether we should put testing effort into
> >> >>Kirkwood for F18.
> >> >>
> >> >>My thought is that the latest plugs are moving to ARMv7, and so
> >> >>as the cutting edge Linux distro, we should make plans for
> >> >>deprecating support over the coming releases. This is not a call
> >> >>to drop support today. If I can get numbers on how many people
> >> >>care, that will help.
> >> >
> >> >I bought several Kirkwood devices with the expectation to run
> >> >Fedora on them and would like to test it at least on a Seagate
> >> >Dockstar, but the little instructions and installer support
> >> >always scared me away.
> >>
> >> Till,
> >>
> >> I've recently updated the Fedora install instructions for the
> >> Pogoplug with is in the same family of devices and leverages the
> >> same uboot update process that dockstar does.
> >>
> >> https://fedoraproject.org/wiki/Architectures/ARM/PogoplugUSBDisk
> >>
> >> As long as uboot is configured correctly, the process is as simple
> >> as dd the image to a USB drive.
> >>
> >> >
> >> >It also includes instructions to update the boot loader and
> >> >supports installing on USB, SD card and eSATA. The Fedora
> >> >instructions only mention to dd an image on a SD card on the
> >> >other hand.
> >>
> >> You'll note that it's not Debian directly providing that support or
> >> information. It's the Debian community and specifically one user.
> >
> > It is at least the documentation that is directly linked at
> > http://www.debian.org/ports/arm/
> >
> >> The same goes for Fedora, because of the man power requirements it
> >> is up to the community to support re-used consumer appliances like
> >> the Dockstar/Pogoplug. If you are successful in getting Fedora on
> >> your Dockstar, we would greatly appreciate a contribution of your
> >> experience and instructions on the wiki.
> >
> > It seems that the disk image boots on the dockstar, but a first "yum
> > update" got oom-killed and there seems to be no swap and not LVM on
> > the image to easily change this. IMHO a problem with the Fedora ARM
> > documentation is, that it is only a collection of reports from
> > people how they did it. It is lacking information about why
> > something was done as described or how it should be done. For
> > example the Debian documentation clearly states which uboot version
> > is required and how to update it. The Kirkwood documentation in the
> > Fedora ARM wiki only says that the proper uboot config depends on
> > the uboot version and gives an example that is supposed to work on
> > a Guru Plug Server Plus. Comparing it with the Debian documentation
> > it also shows that different hex values (addresses?) are used in
> > the uboot config for the kernel and initramfs. But why do they need
> > to be different? Or do they not need to be different? Also as far
> > as I can see there are no instructions about how the images are
> > created and why they have been chosen the way they are (no LVM, no
> > swap, device dependent names for kernel and initramfs, vfat
> > for /boot).

not that it will explain everything but Debian ships uboot for the
kirkwood devices and add features not found in the stock uboot. ext2
support being one of them which is why /boot is vfat we support the
stock uboot and only ship uboot where we have to preferring instead that
the vendors be responsible for supporting and supplying uboot binaries.
we are still evolving the image creation process. in f17 it was a shell
script that used yum. we are moving to use kickstarts and anaconda via
livemedia-creator 

> Well you could always step up to help improve that documentation
> rather than complain ;-)
> 
> > From my outsider POV the ARM SIG looks not very organised which
> > makes it also hard to help now and then. For example I would more
> > or less reduce the wiki install contents to the difference to the
> > shown Debian documentation to avoid duplicate content and trust
> > that they chose sane values, for example for the uboot version and
> > the uboot config. But then it is unclear whether Fedora needs a
> > different uboot config.
> 
> It's not so much a lack of organisation but rather a lack of people to
> do things. There's about 6 of us that do things regularly and between
> us we might make up the equivalent of 1.5 full time people.
> 
> Those of us that are actively working on it are having a hard time
> just keeping up with core tasks of building a some what working distro
> let alone producing a lovely working polished wiki with step by step
> howtos for the 100s of devices out there.
> 
> We are well aware that there are issues with documentation and a whole
> lot of other things. We're working through things as time and
> materials are available. All help is welcome including improving the
> howtos and documentation on supporting each device. I would absolutely
> love someone with ideas on improving the way the wiki is laid out for
> things like device support howto  to step up and implement the general
> layout framework with some place holders for various devices so
> interested people with those devices can add appropriate information.
> 

I second what Peter said here. help is welcome and wanted.

Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlBz7rUACgkQkSxm47BaWffxSwCgj0cUXXWZJxAjw+OVXH7GGQ/j
t0YAn32WZ+7iiUguykWN5PfWW9OYyLuf
=l17F
-----END PGP SIGNATURE-----


More information about the arm mailing list