FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Kubuntu User

LinkBack Thread Tools
Old 04-27-2012, 02:59 PM
Default Add support to determine the ARM processor variety and select the correct kernel to install.

From: "d.marlin" <dmarlin@redhat.com>

Signed-off-by: David A. Marlin <dmarlin@redhat.com>
pyanaconda/iutil.py | 36 ++++++++++++++++++++++++++++++++++++
pyanaconda/platform.py | 5 +++++
pyanaconda/yuminstall.py | 6 ++++++
3 files changed, 47 insertions(+), 0 deletions(-)

diff --git a/pyanaconda/iutil.py b/pyanaconda/iutil.py
index dd691dc..2864980 100644
--- a/pyanaconda/iutil.py
+++ b/pyanaconda/iutil.py
@@ -656,6 +656,42 @@ def getPPCMacBook():
return 1
return 0

+## Get the ARM processor variety.
+# @return The ARM processor variety type, or 0 if not ARM.
+def getARMMachine():
+ if not os.uname()[4].startswith('arm'):
+ return 0
+ armMachine = None
+ machine = None
+ # ARM machine hash
+ armType = {
+ 'OMAP3 Beagle Board' : 'omap',
+ 'OMAP4 Panda board' : 'omap',
+ 'trimslice' : 'tegra',
+ 'Marvell GuruPlug Reference Board' : 'kirkwood',
+ 'Efika MX' : 'imx',
+ 'Genesi Efika MX' : 'imx',
+ 'Genesi Efika MX (Smartbook)' : 'imx',
+ 'Highbank' : 'highbank',
+ }
+ f = open('/proc/cpuinfo', 'r')
+ lines = f.readlines()
+ f.close()
+ for line in lines:
+ if line.find('Hardware') != -1:
+ machine = line.split(':')[1]
+ if machine is not None:
+ for type in armType.items():
+ if machine.find(type[0]) != -1:
+ armMachine = type[1]
+ return armMachine
cell = None
## Determine if the hardware is the Cell platform.
# @return True if so, False otherwise.
diff --git a/pyanaconda/platform.py b/pyanaconda/platform.py
index 335ab5c..5c6ddea 100644
--- a/pyanaconda/platform.py
+++ b/pyanaconda/platform.py
@@ -348,6 +348,7 @@ class Sparc(Platform):
return start+1

class ARM(Platform):
+ _armMachine = iutil.getARMMachine()
_bootloaderClass = bootloader.GRUB2
_boot_stage1_device_types = ["disk"]
_boot_mbr_description = N_("Master Boot Record")
@@ -356,6 +357,10 @@ class ARM(Platform):

_disklabel_types = ["msdos"]

+ @property
+ def armMachine(self):
+ return self._armMachine
def getPlatform(anaconda):
"""Check the architecture of the system and return an instance of a
Platform subclass to match. If the architecture could not be determined,
diff --git a/pyanaconda/yuminstall.py b/pyanaconda/yuminstall.py
index 109daec..d762959 100644
--- a/pyanaconda/yuminstall.py
+++ b/pyanaconda/yuminstall.py
@@ -1452,6 +1452,12 @@ reposdir=/etc/anaconda.repos.d,/tmp/updates/anaconda.repos.d,/tmp/product/anacon
if selectKernel("kernel-PAE"):
foundkernel = True

+ if not foundkernel and iutil.isARM():
+ armMachine = iutil.getARMMachine()
+ if armMachine is not None:
+ selectKernel("kernel-" + armMachine)
+ foundkernel = True
if not foundkernel:


Anaconda-devel-list mailing list
Old 04-27-2012, 09:46 PM
Jon Masters
Default Add support to determine the ARM processor variety and select the correct kernel to install.

On 04/27/2012 11:54 AM, Matthew Garrett wrote:
> On Fri, Apr 27, 2012 at 10:44:08AM -0500, David A. Marlin wrote:
>> Matthew Garrett wrote:
>>> Well ugh. Any chance of the kernel being able to expose this
>>> mapping, since presumably it already exists there in some form?
>> Not that I have found. For more details, please see my response to
>> David Cantrel's comments.
> I know the kernel doesn't at the moment, but we have its source code as
> well...

Well, the kernel does expose what we want...kinda. We have a
"compatible" property in the device tree that exposes, e.g.:

[root@hsv-panda-3-v5tel devices]# xxd /proc/device-tree/compatible
0000000: 7469 2c6f 6d61 7034 2d70 616e 6461 0074 ti,omap4-panda.t
0000010: 692c 6f6d 6170 3434 3330 00 i,omap4430.

Note that this is not "omap", but it would match on "omap*" if we were
allowed to have a "mapping" at the sub-arch level rather than at the
machine specific level (which I can totally see why you dislike that -
there could be any number of new machines, but the odds of a new
sub-arch like "omap" coming or going are far less common). On Calxeda's
"highbank" system, we actually get exactly "highbank" in the compatible
string. I would suggest these options exist:

1). We use the device-tree property "compatible", we adopt an interim
solution for compatibility with current systems that allows a limited
"hashmap" of sorts (but not machine specific, just "omap*", etc.), and
meanwhile have upstream add the right compatible entries to their dtb
(device tree blob - the generated version of the device tree data, which
you can think of as being a flatfile version of OpenFirmware).

2). We use the device-tree property "compatible" but we refuse to work
with anything that doesn't have an up-to-date enough dtb to contain an
appropriate generic entry like "highbank", "omap", etc. This assumes
we'll keep our kernel names matching closely enough - e.g. our "omap"
kernel is actually supporting OMAP3 and OMAP4 derived platforms. But I
suspect since this is common, we can get "omap" to be used in dtb.

3). We introduce a more generic kernel platform determination mechanism,
and add a file somewhere (sysfs, procfs, an entry in cpuinfo) that
always describes the base platform as a string.

4). We do something specific in Fedora kernels that impacts uname output
or similar such that we can determine the platform.

5). We have some generic utility created across ARM distros that can be
used for this (and also to determine other stuff, like virt support -
though we have some logic in our Fedora specific tools for that now). We
could also have this exposed in the kernel HWCAPs and then have a
utility that could pick it up out of the env, in addition to Anaconda.

Other options exist, too. These are just 5 for you to give me feedback
on. Meanwhile, David has something working we can manage with while we
wait for your upstream-Anaconda-acceptable suggestions.



Anaconda-devel-list mailing list
Old 07-11-2012, 08:01 PM
"David A. Marlin"
Default Add support to determine the ARM processor variety and select the correct kernel to install.

Attached is my latest version of this patch. It was made against the
current anaconda/master and applied to 17.29 for testing on F17.


David A. Marlin wrote:

Attached is my latest version of the ARM processor variety patch. It
incorporates suggestions made previously, and was made against
anaconda/master (but applied to 17.29 for testing).

I simplified the hash/lookup by consolidating some machine types, but
I understand this may still be unacceptable. I am currently tracking
master and carrying these patches locally. I keep the rpms in a local
repo for testing.

We are working on a method of exposing the platform in userspace, but
that is not in place yet. Would it be possible to accept this as an
interim solution with the expressed intent that the hash would be
removed as soon as an alternative solution is available? If not,
would a version of this patch with the hash/lookup stubbed out be
acceptable? I would like to get as much of this upstream as possible,
to minimize the patch(es) I need to carry locally and simplify keeping
up with master. Any suggestions are appreciated.

Note: We successfully completed a test kickstart install on an ARM
system today using the modified anaconda-17.29.



Anaconda-devel-list mailing list

Anaconda-devel-list mailing list

Thread Tools

All times are GMT. The time now is 08:58 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org