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: selectKernel("kernel")
On Fri, Apr 27, 2012 at 09:59:28AM -0500, d.marlin wrote:
- if not os.uname()[4].startswith('arm'):
return 0
Just use isARM()?
'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',
Well ugh. Any chance of the kernel being able to expose this mapping, since presumably it already exists there in some form?
Matthew Garrett wrote:
On Fri, Apr 27, 2012 at 09:59:28AM -0500, d.marlin wrote:
- if not os.uname()[4].startswith('arm'):
return 0
Just use isARM()?
Good point. I'll make that change.
'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',
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.
d.marlin
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...
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.
Thanks,
Jon.
On Fri, Apr 27, 2012 at 05:46:39PM -0400, Jon Masters wrote:
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:
Oh, excellent. That seems like a much better plan.
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).
Are any of these provided by the firmware rather than the kernel? Changing existing entries that are potentially being consumed by userspace in some way doesn't seem ideal. Possible stretch - could the existing omap kernel package include Provides: for kernel-omap4430, for instance? Then all the naming and policy could be in one place, avoiding the case where you decide to merge or split an existing kernel binary.
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.
It'd probably be nice to at least have the compatible: property available via sysfs in order to avoid parsing binary.
4). We do something specific in Fedora kernels that impacts uname output or similar such that we can determine the platform.
Doesn't seem ideal, unless it'd get upstream traction. No real reason to create extra problems for any downstream derivatives.
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.
Seems to be an extra layer of indirection, since that'd need to solve the same set of problems in the first place. Just moving the complexity out of Anaconda and into another bit of userspace doesn't win us a great deal.
+## 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]
Once you've found what you're looking for, you should break out of the loop. There's no need to keep looking.
- if machine is not None:
for type in armType.items():
if machine.find(type[0]) != -1:
armMachine = type[1]
Same here.
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: selectKernel("kernel")
You've gone to the trouble of making a property on the platform, might as well use it here instead of calling back into iutil: anaconda.platform.armMachine.
- Chris
Comments below.
On Fri, Apr 27, 2012 at 09:59:28AM -0500, d.marlin wrote:
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
I really _really_ dislike things like the armType hash. I know we have it for ppc, but none of us were consulted when those names were ending up in the kernel and packages.
Is there no way to get the strings like omap, tegra, kirkwood, imx, and highbank from /proc/cpuinfo -or- from somewhere else in /sys? And if not, why? I would very much prefer that we just be able to extract that string from some info the kernel provides than to carry this list which will need updating, and probably a lot because it's ARM.
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)
Yuck, but ok. Would be nice if a single kernel package could happen for ARM. Maybe someday
foundkernel = True
if not foundkernel: selectKernel("kernel")
-- 1.7.6.5
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
David Cantrell wrote:
Comments below.
On Fri, Apr 27, 2012 at 09:59:28AM -0500, d.marlin wrote:
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
I really _really_ dislike things like the armType hash. I know we have it for ppc, but none of us were consulted when those names were ending up in the kernel and packages.
Is there no way to get the strings like omap, tegra, kirkwood, imx, and highbank from /proc/cpuinfo -or- from somewhere else in /sys? And if not, why? I would very much prefer that we just be able to extract that string from some info the kernel provides than to carry this list which will need updating, and probably a lot because it's ARM.
I understand and agree. I have not been able to find this information any where else (yet). I will do some more checking and see if there's anything I have overlooked. I know it is not available in /proc/cpuinfo, and have not been able to find it anywhere in /sys. I will dig some more.
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)
Yuck, but ok. Would be nice if a single kernel package could happen for ARM. Maybe someday
There is an effort underway to unify several of the ARM kernel variants by making use of Flattened Device Tree, but I'm afraid even merging the most common platforms into a single kernel will still take some time. Unfortunately, just building from a single code base is a recent accomplishment, but progress is being made.
foundkernel = True
if not foundkernel: selectKernel("kernel")
-- 1.7.6.5
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Fri, Apr 27, 2012 at 09:59:28AM -0500, d.marlin wrote:
From: "d.marlin" dmarlin@redhat.com
[snip]
Also, there's no reason to CC clumens@redhat.com on messages you send to anaconda-devel-list. He's a member of that list.
anaconda-devel@lists.stg.fedoraproject.org