OpenELEC Testbuilds for RaspberryPi - Printable Version +- Kodi Community Forum (https://forum.kodi.tv) +-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33) +--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111) +---- Forum: Raspberry Pi (https://forum.kodi.tv/forumdisplay.php?fid=166) +---- Thread: OpenELEC Testbuilds for RaspberryPi (/showthread.php?tid=140518) Pages:
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
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
|
RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-01-17 (2013-01-16, 12:06)tuxen Wrote: Edit: Do you have the incorrect bogomips bug? Or knows where it comes from? It's still present. Do you have force_turbo enabled (note: can void warranty). I do, and my bogomips value is correct: Code: gpu_mem=128 Code: root ~ # dmesg|grep -i bogo (Note: this is a custom build of OpenELEC that I built last night, the only difference between Master and my build are modifications in my build to fix NFS auto-update, so nothing that would account for any bogomips difference) RE: OpenELEC Testbuilds for RaspberryPi - pplucky - 2013-01-17 (2013-01-17, 11:58)MilhouseVH Wrote:I don't (my overclock is supposed to be dynamic) and this is what I get:(2013-01-16, 12:06)tuxen Wrote: Edit: Do you have the incorrect bogomips bug? Or knows where it comes from? It's still present. Code: root ~ # dmesg|grep -i bogo RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-01-17 (2013-01-17, 02:25)tuxen Wrote: But the failure here is you can not use the systeminfo screen to measure CPU idle usage neither must you be on this screen while measuring with top. For anyone that might be interested, I've written a simple script to monitor Raspberry Pi vital stats such as current ARM/Core/GPU frequency, current temp (and max temperature achieved), current Core/SDRam voltage, IRQ/s, network RX/s and TX/s, CPU load, memory used/free. Will also display current memory config and which codecs are hardware enabled. Code: wget http://www.nmacleod.com/public/bcmstat.sh && chmod +x ./bcmstat.sh The load stats will be equivalent to those in top, and the other information can be useful when monitoring network and other performance issues (eg. is your CPU frequency increasing as expected or stuck at stock etc.). (2013-01-17, 12:09)pplucky Wrote: I don't (my overclock is supposed to be dynamic) and this is what I get: Then I think what you are seeing is "by design" - your Pi will boot at the stock 700MHz speed, and this speed will be used to calculate the bogomips value. What overclock settings do you have in your config.txt, as admittedly your bogomips value is on the low side. Another option to add to your config.txt is "initial_turbo=30" which should see your Pi calculate a more accurate bogomips without forcing turbo all the time (it will just be enabled for the first 30 seconds during boot). If you want to monitor your CPU frequency, try the script I have linked in the post above. RE: OpenELEC Testbuilds for RaspberryPi - pplucky - 2013-01-17 (2013-01-17, 12:11)MilhouseVH Wrote:This is what I currently have on my config.txt:(2013-01-17, 12:09)pplucky Wrote: I don't (my overclock is supposed to be dynamic) and this is what I get: Code: gpu_mem=100 Usually I use SSH command 'vcgencmd measure_clock arm' to get my current CPU frequency... RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-01-17 (2013-01-17, 12:56)pplucky Wrote: Usually I use SSH command 'vcgencmd measure_clock arm' to get my current CPU frequency... Yes, that's what the script uses but is also a little more informative - it will run continuously and periodically (default every 2 seconds) show you current values for most measurable items relating to Pi hardware. RE: OpenELEC Testbuilds for RaspberryPi - tfft - 2013-01-17 (2013-01-16, 14:00)tfft Wrote: The compilation process grabs various packages from the openelec.tv's sources directory from the web, so there are files listed there akin to,I just downloaded the xbmc github tree and was able to find the FF434FE string above (as an example); I then looked for the current xbmc PKG_VERSION (F70EB43) and that got me nowhere (its NOT part of the xbmc github log) - can someone please shed some light on where this hash is coming from ? I'd like to know which xbmc snapshot is being grabbed as compared to whats on github. Is a different/private repository for xbmc being used ? Thanks. RE: OpenELEC Testbuilds for RaspberryPi - sraue - 2013-01-17 (2013-01-17, 14:23)tfft Wrote:(2013-01-16, 14:00)tfft Wrote: The compilation process grabs various packages from the openelec.tv's sources directory from the web, so there are files listed there akin to,I just downloaded the xbmc github tree and was able to find the FF434FE string above (as an example); I then looked for the current xbmc PKG_VERSION (F70EB43) and that got me nowhere (its NOT part of the xbmc github log) - can someone please shed some light on where this hash is coming from ? I'd like to know which xbmc snapshot is being grabbed as compared to whats on github. xbmc-f70eb43.tar.xz ---> https://github.com/xbmc/xbmc/commit/f70eb43ebc8ed2475296ff997214cc56fccce531 RE: OpenELEC Testbuilds for RaspberryPi - tfft - 2013-01-17 (2013-01-17, 14:46)sraue Wrote:Strange - on github's web pages the hash noted doesn't resolve (it doesn't show-up in the 'git log' output either) and is not there even if 'gitk' is used. Oddly enough these two commits are equivalent,(2013-01-17, 14:23)tfft Wrote: I then looked for the current xbmc PKG_VERSION (F70EB43) and that got me nowhere (its NOT part of the xbmc github log) - can someone please shed some light on where this hash is coming from ? I'd like to know which xbmc snapshot is being grabbed as compared to whats on github.xbmc-f70eb43.tar.xz ---> https://github.com/xbmc/xbmc/commit/f70eb43ebc8ed2475296ff997214cc56fccce531 https://github.com/xbmc/xbmc/commit/1336ec731ff02fbcfa262140d531f50992624357 https://github.com/xbmc/xbmc/commit/f70eb43ebc8ed2475296ff997214cc56fccce531 The only difference I can see is that 'S. Davilla' committed again but why doesn't that commit show-up in github's mainpages ? Shouldn't every commit be available and accessible through the logs ? Very strange... Thanks for replying - I was (still am) rather baffled and wondering how to decipher such oddities in the future. RE: OpenELEC Testbuilds for RaspberryPi - sraue - 2013-01-17 (2013-01-17, 15:47)tfft Wrote: Strange - on github's web pages the hash noted doesn't resolve (it doesn't show-up in the 'git log' output either) and is not there even if 'gitk' is used. Oddly enough these two commits are equivalent, change to the Frodo branch, or checkout the frodo branch and you will find this commit :-) RE: OpenELEC Testbuilds for RaspberryPi - tuxen - 2013-01-17 (2013-01-17, 11:58)MilhouseVH Wrote:I sure do and measuring from cmdline shows correct clock, this is only with rbej's build.(2013-01-16, 12:06)tuxen Wrote: Edit: Do you have the incorrect bogomips bug? Or knows where it comes from? It's still present. As he said himself he had the bug to I guess it was normal in he's builds. (look at post #895) Therefore the question was more directed at him. I guess he has a bug somewhere then? I know all about warranty and stuff I'm more worried about the other hardware as I had to replace a sdcard slot and I was not even pressing hard or anything it just snapped the edge holding one side. =) Another pi arrived with the capacitor broken off ordered from RS board from china I also had to fix that after waiting months I was not prepared to wait god knows how long for a return. I have complained to RS though. No answer yet. Edit: just checked dmesg and bogomips are calculated wrong there. (697) I also have some "cpufreq: switching to governor on demand" at the end shouldn't this be disabled? vcgencmd measure_clock arm is correct though 1050Mhz at idle. RE: OpenELEC Testbuilds for RaspberryPi - tuxen - 2013-01-18 Oh and thanks for the script.. Everything shows correct. Weird. Let's see with the next rbej build if he is nice enough to share it with us. I know I'm lazy for not setting up a build environment and getting familiar with the process but I'm not complaining either its just odd. Edit: I guess it also could be the firmware or maybe more likely "special rpi kernel 3.6.y" which I don't know what means. Which kernel and firmware are you using in your build MilhouseVH? RE: OpenELEC Testbuilds for RaspberryPi - rbej - 2013-01-18 Kernel Rpi 3.6.y is one and only official proper kernel for Rpi. https://github.com/raspberrypi/linux/commits/rpi-3.6.y RE: OpenELEC Testbuilds for RaspberryPi - tuxen - 2013-01-18 Thanks rbej. It just sounded more exotic to me than the boring 3.6.11 uname -a gives me Looking forward to test a new build. No idea why it calculates the delay loop wrong then. RE: OpenELEC Testbuilds for RaspberryPi - gizmomel - 2013-01-18 hopefully not going too far off topic - but has anyone managed to integrate (as a plugin, or seperate) NZBGET with openelec / xbmc please? not wanting to download while I'm watching things of course, but my Pi uses a lot less power than my desktop while downloading. RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2013-01-18 (2013-01-18, 16:37)gizmomel Wrote: hopefully not going too far off topic - but has anyone managed to integrate (as a plugin, or seperate) NZBGET with openelec / xbmc please? You can install SABnzbd-Suite as an add-on in OpenELEC, though personally I would run that sort of thing on a separate Pi (running Raspbian, headless...). |