psix1488
, 05:54
За последней месяц ко мне стало попадать довольно много коммуникаторов с приблизительно одинаковыми симптомами.Точнее: съезжание цветов на дисплее, периодические зависания на бутовой картинке с последующим появлением явно заметных полос на экране. Снятие процессора и его последующая накатка положительных результатов не дали, в ходе "оперативно-исследовательских операций" и 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 вполне может уложить аппарат. Не следует забывать что даже процессоры из одной партии не идентичны, погрешность при производстве такова, что один экземпляр может работать годами второй ляжет через неделю.
Одинаковые кристаллы с разными ревизиями ведут себя при оверклокинге по разному.
19294
Разгон OMAP процессоров затрагивает все его блоки. Это связано с тем, что они используют общую частоту, генерируемую из 12Мгц (или 13МГц) задающего тактогенератора путём её умножения и деления (некоторые блоки используют сразу частоту задающего тактогенератора). Эта частота является максимальной для блоков (именно её значение регулирует OmapClock). Но, понятное дело, не всем блокам нужна высокая частота, поэтому большинство блоков имеет делитель частоты (1/2/4/8 ).
Поскольку блоки имеют только делители частоты (множителей нет), то для разгона ARM процессора приходится поднимать общую частоту OMAP процессора. Что и приводит к последствиям.
Сам ARM процессор в нормальном режиме имеет делитель 1, а в спящем режиме 2 (как правило) - для энергосбережения.
В идеале, программа для разгона OMAP процессоров должна позволять устанавливать помимо частоты ещё и делители для отдельных блоков, но таких делителей около дюжины, и человеку, чтобы воспользоваться такой программой, придётся изучить систему частотогенерации в процессоре.
Об этой особенности OMAP процессоров уже вроде как говорили вскоре после выпуска OmapClock, но, видимо, народ подзабыл.
В общем хотелось бы напомнить ещё раз всем: не увлекайтесь экстремальным разгоном.
Изменение частоты на +/- 5-10% теоритически не должно вредить. На практике же каждый сам должен оценивать потенциальный риск связанный с разгоном.
Немного теории… в этих процессорах (см. рисунок) есть три шины:
- 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 вполне может уложить аппарат. Не следует забывать что даже процессоры из одной партии не идентичны, погрешность при производстве такова, что один экземпляр может работать годами второй ляжет через неделю.
Одинаковые кристаллы с разными ревизиями ведут себя при оверклокинге по разному.
19294
Разгон OMAP процессоров затрагивает все его блоки. Это связано с тем, что они используют общую частоту, генерируемую из 12Мгц (или 13МГц) задающего тактогенератора путём её умножения и деления (некоторые блоки используют сразу частоту задающего тактогенератора). Эта частота является максимальной для блоков (именно её значение регулирует OmapClock). Но, понятное дело, не всем блокам нужна высокая частота, поэтому большинство блоков имеет делитель частоты (1/2/4/8 ).
Поскольку блоки имеют только делители частоты (множителей нет), то для разгона ARM процессора приходится поднимать общую частоту OMAP процессора. Что и приводит к последствиям.
Сам ARM процессор в нормальном режиме имеет делитель 1, а в спящем режиме 2 (как правило) - для энергосбережения.
В идеале, программа для разгона OMAP процессоров должна позволять устанавливать помимо частоты ещё и делители для отдельных блоков, но таких делителей около дюжины, и человеку, чтобы воспользоваться такой программой, придётся изучить систему частотогенерации в процессоре.
Об этой особенности OMAP процессоров уже вроде как говорили вскоре после выпуска OmapClock, но, видимо, народ подзабыл.
В общем хотелось бы напомнить ещё раз всем: не увлекайтесь экстремальным разгоном.
Изменение частоты на +/- 5-10% теоритически не должно вредить. На практике же каждый сам должен оценивать потенциальный риск связанный с разгоном.