Последствия разгона OMAP850 (действительно для всех ARM)

# 10 окт 2007, 12:44

За последней месяц ко мне стало попадать довольно много qtek s200 с приблизительно одинаковыми симптомами, а точнее съезжание цветов на дисплее, периодические зависания на бутовой картинке с последующим появлением явно заметных полос на экране. Снятие процессора и его последующая накатка положительных результатов не дали, в ходе "оперативно-исследовательских операций" и SimpleSoft'а был найден предположительный виновник данных багов - разгон процессора.

Немного теории… в этих процессорах (см. рисунок) есть три шины:

- CPU, fCPUCLK
- Advanced High-performance Bus (AHB), fHCLK
- Advanced Peripheral Bus (APB), fPCLK

так называемая частота fCPUCLK(её частота как правило в 2 раза выше HCLK), fHCLK- (скоростная шина на ней висят видеоадаптер, SDRAM и т.д. ), fPCLK (на ней висят USB, UART\Irda\COM-порты… ). При разгоне мы увеличиваем множитель, который вляет на работу CPUCLK, согласованием работы ядра и шины занимается арбитр, но последствия оверклокинга на него влияют похоже не благоприятно. Плывёт шина HCLK, мы ускоряем работу с SDRAM, за счёт этого получаем прирост производительности, но при этом разгон затрагивает и LCD-контролер ибо он завязан на частоте этой шины, т.е. там стоят щётчики которые высчитывают сколько клоков подать на одну ножку вывода сколько на другую. При поднятии частоты шины диаграмма работы этих выводов измениться и контроллер будет работать в режиме с не корректной временной зависимостью… но даже при этом “сгореть” он не может, при каких либо багах достаточно вернуть частоту на место. Проблема вероятней всего в самой шине, что-то изменяется в её диаграмме работы поэтому перестают правильно захватываться пиксель-блоки или плывёт синхронизация. Также на некоторых аппаратах пропадает Wi-Fi (он тоже сидит на HCLK) был случай с “исчезнувшим” радиомодулем.
Итак, советую сильно задуматься любителям разгона OMAP, ибо этот высокоинтегрированый проц, явно не заточен под разгон, разработчики ставили во главу угла стоимость и энергопотребление. Имхо, временный разгон врят ли может привести к плачевным последствиям, а вот постоянный разгон при помощи, например, BatteryStatus или OmapClock вполне может уложить аппарат. Не следует забывать что даже процессоры из одной партии не идентичны, погрешность при производстве такова, что один экземпляр может работать годами второй ляжет через неделю.
Одинаковые кристаллы с разными ревизиями ведут себя при оверклокинге по разному.

# 10 окт 2007, 13:36

В общем-то Nosferatos правильно всё сказал - разгон OMAP процессоров затрагивает все его блоки. Это связано с тем, что они используют общую частоту, генерируемую из 12Мгц (или 13МГц) задающего тактогенератора путём её умножения и деления (некоторые блоки используют сразу частоту задающего тактогенератора). Эта частота является максимальной для блоков (именно её значение регулирует OmapClock). Но, понятное дело, не всем блокам нужна высокая частота, поэтому большинство блоков имеет делитель частоты (1/2/4/8 ).

Поскольку блоки имеют только делители частоты (множителей нет), то для разгона ARM процессора приходится поднимать общую частоту OMAP процессора. Что и приводит к последствиям.

Сам ARM процессор в нормальном режиме имеет делитель 1, а в спящем режиме 2 (как правило) - для энергосбережения.

В идеале, программа для разгона OMAP процессоров должна позволять устанавливать помимо частоты ещё и делители для отдельных блоков, но таких делителей около дюжины, и человеку, чтобы воспользоваться такой программой, придётся изучить систему частотогенерации в процессоре.

Об этой особенности OMAP процессоров уже вроде как говорили вскоре после выпуска OmapClock, но, видимо, народ подзабыл.

В общем хотелось бы напомнить ещё раз всем: не увлекайтесь экстремальным разгоном.

# 10 окт 2007, 14:47

intruders писал(а):В идеале, программа для разгона OMAP процессоров должна позволять устанавливать помимо частоты ещё и делители для отдельных блоков, но таких делителей около дюжины

ну хорошо, если этими делителями в принципе можно управлять - можно не обременять пользователя ручной установкой делителей, а сделать типа набора "пресетов", типа "разгон только ядра", или опцию "разгонять только ядро". Я в том смысле, что если проблема только в том, чтобы не обременять пользователя кучей параметров - то это не проблема ИМХО.

# 10 окт 2007, 15:16

Nob писал(а):если этими делителями в принципе можно управлять

Делители можно задавать, это факт.

Nob писал(а):можно не обременять пользователя ручной установкой делителей, а сделать типа набора "пресетов", типа "разгон только ядра", или опцию "разгонять только ядро".

Всё бы хорошо, да придётся делать пресеты под каждый девайс в отдельности, т.к. множители/делители скорее всего будут отличаются. А поскольку в ARM процессоре (и в других блоках тоже) множителя нету, а есть только делитель, то разогнать независимо отдельный блок не выйдет, его можно только притормозить.

Nob писал(а): Я в том смысле, что если проблема только в том, чтобы не обременять пользователя кучей параметров - то это не проблема ИМХО.

Конечно это не проблема пользователя - это проблема для программера, ИМХО

Представь сколько надо тестить, чтобы найти работающие комбинации для различных девайсов.

В общем в данный момент ситуация с разгоном OMAP процессоров обстоит примерно как на PC - т.к. разгон достигается за счёт повышения частоты "системной шины", то частота отдельных узлов тоже поднимается. Чтобы эти узлы не глючили и не сдохли от завышенной частоты, применяется более высокий делитель шины. На PC проще - там есть BIOS, который выставляет нужные делители в зависимости от частоты шины, а вот на смартах/покетах этого нет (нет такой программы).

Когда я писал OmapClock, то поначалу думал сделать возможность управления и делителями, но потом решил, что это будет слишком навёрнуто и в итоге отказался.

# 12 окт 2007, 11:42

intruders,
Так получаестя, прога Торнадо паур контроль, в состав которой входит Омапклок, является потенциально опасной прогой для смартов, или если её использовть на частоте 180(тоесть не превышать 195 заявленных производителем)), то на Qtek 8310 то это не опасно?

# 12 окт 2007, 12:12

Stink, а смысла тогда её использовать вообще? Разве что яркость подсветки менять...

# 12 окт 2007, 12:19

Nosferatos,
Да именно для яркости!

# 12 окт 2007, 12:41

Stink писал(а):если её использовть на частоте 180(тоесть не превышать 195 заявленных производителем

Изменение частоты на +/- 5-10% теоритически не должно вредить. На практике же каждый сам должен оценивать потенциальный риск связанный с разгоном.

# 12 окт 2007, 12:55

Stink, ну конечно можно, если ты разгон не трогаешь, то в чем проблема...
intruders, так в ней шаг очень большой, самый маленький персет 227Мгц это уже не 5%

# 12 окт 2007, 13:06

Nosferatos писал(а): в ней шаг очень большой, самый маленький персет 227Мгц это уже не 5%

Ну, это уже её проблема - в OmapClock можно выставить ещё
204MHz и 216MHz, почему автор пауэр контрола решил их не использовать - хз.

# 12 окт 2007, 16:11

Итого, что мы имеем: Если отсавить стандартную частоту этой проги на 180, и уменьшать подсветку, то всё будет гуд?

# 12 окт 2007, 16:17

все будет гуд!

# 12 окт 2007, 16:59

Камрады, всем спасибо за ответы, примного благодарен за помощь!

# 14 окт 2007, 08:09

а смысла тогда её использовать вообще? Разве что яркость подсветки менять...

А есть ли какой-л твик или прога для смены подсветки (а то уж совсем тупо Tornado Power Control для этого гонять :lol:

)?

P.S.: Огромное спасибо за тему - теперь я получил подтверждение своим опасениям!

# 14 окт 2007, 09:43

andrew7777777 писал(а):прога для смены подсветки

Tornado Low Light