/
board-mappings.ini
98 lines (88 loc) · 3.28 KB
/
board-mappings.ini
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
### Don't edit this file manually. Update it in git, if there's a good reason to do so ###
#
# This file is used by SSU to find out which device (or device variant) it's
# running on, and use this information to look for device family, and device
# specific adaptation(s). The last two values are used when resolving URLs,
# and therefore change depending on vendor setup.
#
# To avoid quoting in the search strings SSU will do each checks on the
# _value_, and return the key, if successful. The device model returned
# my either be the device model, or a variant. Before resolving the family
# and adaptations variants will be resolved through entries under the
# variants category.
#
# Valid categories for determining the model:
# - file.exists -- checks for existince of a file in the filesystem
# - boardname.equals -- compares with boardname
# - boardname.contains -- searches for substring in boardname
# NOTE: only use boardname if none of the other options match
# use the boardname command to set/check the current value
# - systeminfo.equals -- compares the model returned by QSystemInfo
# with the value provided
# NOTE: systeminfo matching is currently disabled, as this would
# pull in the whole X11 stack, and on Mer/Nemo does cpuinfo
# matching only anyway, which ssu can do better already.
# - cpuinfo.contains -- searches /proc/cpuinfo for a string
# - uname-release.contains -- searches the kernels release string for
# a string (uname -r)
# - arch.equals -- compares with zyppers arch (like i586)
#
# Resolve order is:
# file.exists -> systeminfo.equals -> cpuinfo.contains
# -> uname-release.contains -> arch.equals
#
# The found model (after resolving variants) will be used as category. The
# following keys are valid there:
# - family -- the device family, used for the family specific adaptation
# - adaptation-repos -- list of adaptation repositories for this family
#
# The value of adaptation-repos gets converted into a QStringList, which
# uses commas as separator. If one of the adaptation names contains a comma
# it needs to be quoted:
# adaptation-repos=foo
# adaptation-repos="foo, bar", baz
# adaptation-repos=foo, bar, baz
#
# The adaptation list is used to create repo files for adaptation repos.
# A repository named 'adaptation0' operates on the first list element,
# 'adaptation2' on the 3rd, etc. The matching item in the list will be
# exported as adaptation variable.
#
# Freeform variable sections start with 'var-'. A variable section for an
# adaptation named 'n9xx' would be 'var-n9xx'. A variable section may
# contain freeform variables, or the keyword 'variables' to include any
# other section. Currently only one section may be included, and you may
# not specify additional variables:
#
# [var-n9]
# foo=bar
# bar=baz
#
# [var-n950]
# variables=n9
#
# The N9x mappings should be solved through sysinfo, but that's currently
# broken on Mer/Nemo
[file.exists]
SDK=/mer-sdk-chroot
[systeminfo.equals]
[cpuinfo.contains]
N900=Nokia RX-51 board
N950=Nokia RM-680 board
N9=Nokia RM-696 board
[arch.equals]
generic-x86=i586
[variants]
N950=N9
[N9]
family=n950-n9
adaptation-repos=n9xx-common,n950-n9
[N900]
family=n900
adaptation-repos=n9xx-common,n900
[SDK]
[generic-x86]
family=x86
adaptation-repos=x86
[UNKNOWN]
family=UNKNOWN