Через тернии разработки ПК
В преддверии выставки Computex 2015 наша компания выпустила статью о новом, еще более мощном мини-компьютере. Но так ли легко было нам, разработчикам этого продукта? Сколько бессонных ночей стоила эта разработка инженерам, сколько проблем пришлось решить и подводных камней обойти? В этой статье нам хотелось бы рассказать о самом начале этого пути, это был 2009 год, «мы выживали как могли». Я думаю, дорогой читатель, Вам будет интересно почитать, какие грабли и с какой силой нас колошматили за время создания первой платы.
Немного истории
В начале 2009 года руководство компании принимает решение создать, а точнее — возродить направление разработки вычислительной техники. История компании довольна долгая, можно лишь упомянуть, что в 80-е годы компания участвовала в разработке ПК «Ириша». И вот, 2009 год, официальное тайваньское отделение «Communication Technology» начинает вести диалог с компанией Intel и её официальным дистрибьютером на Тайване. В итоге мы получаем документы на платформу Intel PineTrail-M TigerHill — это дуэт процессора Intel Atom серий N400/D500 и чипсета NM10. Для отладки первой версии нашей платы было решено развести её в форм-факторе COM Express. Это такой модуль мезонин 95×95 мм, с длинным многоконтактным разъемом. И чтобы Вы понимали всю суровость ситуации, схема модуля и разводка были сделаны не в какой-то там новомодной Cadence или Altium, а в старом ламповом PCAD 2006.На фотографии уже вторая ревизия этого модуля:
Пациент скорее жив… Вот представьте. Распаяно 5 модулей. Ложатся мне на стол. Нужно срочно запускать. Я на Тайване, мой начальник в Москве. Документов от Intel — референс-схема, руководство по дизайну для разводчика и пару даташитов на чипсет и процессор. Все, больше ничего нет.Хочу вам сказать что мой непосредственный руководитель — Сорокин Анатолий Викторович, прекрасный и опытный инженер, который изменял схемотехнику для совместимости с COM Express удалил из неё так называемый EC — Embedded Controller. Эта микросхема отвечает за запуск и контроль питаний, управление вентиляторами и т.п. вещами. Соответственно цепочка запуска питаний стала банально проста, питания просто поднимались друг за другом и в конце концов поднимался общий так называемый POWER_GOOD, сообщая чипсету о готовности всех питаний. Принципиально, этот EC абсолютно не нужен на данном модуле, он может быть установлен на материнской плате, а может быть и не установлен, заметной роли он не играет.
Плата на столе, пассивная плата (материнка) тоже наша, проста как детекторный приёмник. Два питания — +5B для периферии и +12В для COM Express модуля, запуск которых контролируется небольшим микроконтроллером. Этим же микроконтроллером опрашивается состояние кнопки Вкл, также контролируются некоторые нужные сигналы с чипсета. Это сейчас я знаю, как эта кухня работает, а тогда было ВООБЩЕ НИЧЕГО НЕ ПОНЯТНО.
Ладно, подаем питание от лабораторного источника, нажимаем кнопку включения питания, микроконтроллер поднимает +5В и +12В, дергает на 100 мсек сигнал PWRBTN# и ждет секунду от чипсета поднятия сигнала SUS_S5#. Пока он эту секунду ждал, в воздух взлетел один из танталовых конденсаторов, при пайке перепутали полярность. Хорошо, перепаиваем и проверяем остальные. Парочку пришлось перепаять.
Запускаем опять. SUS_S5# стоит в единице, ничего не происходит, ток потребления небольшой, значит, питания. Замечу, что запуск питаний это вообще самый первый шаг запуска любой платы, но у таких сложных навороченных платформ 10–15 отдельных DC/DC-преобразователей, которые должны запускаться в строгой последовательности, а некоторые даже с задержками. В нашем случае первый шаг — это преобразование +12В в два основных питания +V5A, +V3.3A. A — это основное питание, которое должно запускаться железно по кнопке включения, оно запитывает чипсет.
Ага, эти питания есть. PWRBTN# до чипсета доходит. Следующий шаг — сигнал RSMRST# — Resume Reset. Смотрим откуда он идет, он идет с DC/DC конвертора +V5A/+V3.3A сигналом POWER_GOOD. Не поднимается, зараза, ага, так как питания присутствуют, значит, его нужно притянуть. Притягиваем, RSMRST# поднимается, вслед за этим с чипсета по очереди поднимаются SLP_S5#, SLP_S4# и SLP_S3#. Это так называемые слипы, чипсет говорит платформе — я вошел в состояние S4, врубай периферийное питание (HDD, USB, память и т.д.), я вошел в состояние S3 — врубай питания S для всего остального. Последовательность примерно такая — SLP_S4# → +V5,+V3.3,+V1.8 для запитки DDR. SLP_S3# → +V5S, +V3.3S,+V0.9S для DDR, +V1.5S для блоков CPU и чипсета. +V1.5S_POWER_GOOD → +V1.05S для блоков DMI, Analog DDR, GPIO у CPU и чипсета. Далее +V1.05S_POWER_GOOD → +V0.89 для графического блока CPU. И в конце концов, если все питания встали, все POWER_GOOD собираются «И» логикой в один общий, делается задержка 99 мсек, для стабилизации всех питаний и запускается +VCC_CPU, основное питание процессора. Чиспет при этом ждет PWROK и отдельный VMPWRGD для +VCC_CPU. Фууух… Пару недель совместно с Анатолием бились над этими питаниями, в итоге один из POWER_GOOD нужно было подтянуть, в схеме компаратора для контроля напряжения номиналы поменять, и много там еще чего было, сейчас уже не вспомнить. Как результат — все питания стоят, но система молчит.
Разбираемся дальше. Чипсет по поднятию PWROK и VMPWRGD обязан сообщить процессору CPUPWRGOOD и поднять PLTRST# — Platform Reset. Т.е. он ему говорит — всё, питания ок, отпускаю ресет, стартуй! CPUPWRGOOG поднимается, PLTRST# — нет. Опа… Приплыли… Хорошо, что у меня остались все снятые дампы анализатора, вот он, проблемный:
Две недели мы бились с этой проблемой, чего только не перепробовали. В итоге я нашел одну из нескончаемых потенциальных проблем — один из пинов чипсета должен был быть притянут к земле, а у нас он болтался в воздухе! В общем, мы сняли чипсет с платы, установили тонкую проволочку на контакт и припаяли новый чипсет. И оно заработало! Вот так это выглядело:
Фотографий, как железо выглядит под отладкой, к сожалению, не осталось, но вот, например, плата, а платформе Haswell выглядела у меня на столе так:
Отлично, теперь очередь BIOS. Пока на отладочной плате я вижу код 0×00, а это значит, что загрузка BIOS из SPI EEPROM не осуществляется. Фотография — новодел, материнка была другая, но просто показать, как оно примерно выглядело на столе:
Разбираемся дальше, встаем на SPI_CLK — клок присутствует, запросы идут, встаем на SPI_MOSI — чипсет выдает пачки запросов, встаем на SPI_MISO — ноль. Подтяжка SPI_MISO — и ура, код 0×87. Ну наконец-то. Скорее всего BIOS требует EC. Встаем анализатором на LPC, тестируем и видим запросы на адрес 0×164E и 0×164F, это однозначно EC, после запросов BIOS виснет. Такое:
Отписали в AMI, Phoenix и Insyde. Phoenix прислал бинарник, но он не запустился, Insyde вообще стал задавать тупые вопросы, а в AMI достаточно быстро поняли проблему, и их бинарник завелся с первого раза. Все, основное железо запущено, далее проверяется только периферия.
Неожиданные проблемы с аудио-кодеком После запуска платы прошло некоторое время, мы сделали пассивку с аудио-кодеком от Realtek. Ничего не предвещало беды, HDAUDIO-интерфейс подцепил кодек, устройство увиделось операционкой, даже заработал выход на динамик, но некоторые выходы и входы просто не работали.Отписали в Realtek, пообщались, оказалось, что BIOS, по старту должен залить в аудио-кодек так называемый VERB Table. По сути установить внутренние регистры кодека в соответствии с требованиями использования. Т.е. из всего многообразия выходов — реально может быть использован только один. Таблица эта генерится специальным приложением от Realtek HDACfg. Там указывается вся информация, вплоть до расположения, цвета и типа разъема. Ну вот, приплыли, исходников BIOS нет, AMI за бесплатно нам помогать не стала. Что делать?
Уже даже не помню как, но я отыскал в сети программку (BIOS Patcher 7.0), которая сумела разобрать мне BIOS на составные части. UEFI BIOS представлен как некая капсула, внутри находится древовидная структура из разных типов модулей. Модули в основном запакованы. Причем некоторые своей хитрой компрессией. Ладно, нашел способ распаковать все модули, нашел модуль, отвечающий за инициализацию устройств на шине HDAUDIO. Очень повезло, что таблица одного из устройств была больше моей. Заменил её на свою, и, конечно, не забыл пофиксить длину. А вот собираться оно обратно абсолютно не захотело. Мне очень помог EDK Tianocore, с помощью его утилит, а именно genffsfile, gensection, genfvimage, я вручную собрал все необходимые секции. И оно заработало!
Итог Сейчас я с некоей гордостью, что ли, вспоминаю эти победные моменты, ведь не было ничего, ни документации по запуску платформы, ни исходников BIOS, ни вменяемой поддержки со стороны Intel. Помогала только интуиция и опыт.Теперь это несколько проще, конечно, все исходники у нас есть, поправить что-либо в BIOS можно достаточно быстро, диалог с AMI налажен, глюки я им периодически поставляю и они их правят. Документы от Intel приходят уже полными, т.е. чтобы вы понимали, например, на платформу Broadwell их около 130-ти. В Skylake уже под 400. Но все равно, первая ревизия платы всегда в итоге дорабатывается, всегда где-то что-то не притянуто, или еще какие-то проблемы.
Теперь есть в наличии дебаггер для BIOS, можно посмотреть отладку, и он уже много раз нас выручал. В нашей команде на одного человека больше, замечательный инженер, железячник, который решает кучу проблем. Теперь у нас свои SMD-линии, и таинство опытного производства происходит буквально в соседней комнате. Теперь Intel интегрирует чипсеты в SoC и меньше проблем с разводкой. Теперь у нас много партнеров и контактов по миру. Но тогда были другие времена, «мы выживали как могли»…
На первый раз, пожалуй, всё — казалось бы, всего пара абзацев, а на практике со всем этим мучились около двух месяцев. Если Вам понравилось, то в следующих статьях мы еще расскажем о чём-то подобном, а пока задавайте вопросы в комментариях.
P.S. Ну и, конечно, я, я так выгляжу, когда вхожу в BIOS.
Ссылки: — «Сетевые Технологии»– «Communication Technology»– Raydget Россия– Raydget Тайвань– Карманный десктоп
