Компания Softeq Flash Solutions, R& D центр южнокорейской корпорации SK Hynix, разрабатывает firmware для flash-карт мобильных телефонов и SSD. Сейчас она ищет в команду firmware-инженеров. Dev.by пообщался с руководителем отдела Software Quality Engineering Сергеем Глебовым и узнал, чем занимаются «фирмварщики» и почему это сложнее веб-разработки.
Если не произойдёт атомной войны, то рынок устройств для хранения данных продолжит расти
Чтобы рассказать о романтике FW-разработки, логично будет начать с разговора о рынке и отрасли в целом. Сейчас рынок устройств хранения данных условно поделен на 3 части — старые «механические» HDD, устройства на базе NAND-памяти (SSD, flash-карты), прочая экзотика типа лент для резервного копирования, оптических дисков и иже с ними. Причём доля SSD растет.
Суммарная ёмкость SSD-устройств также постоянно увеличивается, графики в открытых источниках говорят об удвоении каждые два года. Я ежегодно езжу на конференцию Flash Memory Summit, там каждый раз жонглируют статистикой о приросте и составе суммарного мирового объёма данных, хранимых человечеством. Так вот — этот объём сейчас составляет в районе 15 зеттабайт (миллиардов терабайт), причём, что ожидаемо, это не что-то высоконаучное, а видео, селфи с котиками, порнография в конце концов. Всё это надо где-то хранить.
В общем, если не произойдёт атомной войны, то рынок устройств для хранения данных продолжит расти. В будущем, вероятно, ещё скажется тренд на ИИ. То, с чем сейчас работают люди, — это маленькие и глупые нейросети, но скоро они станут умнее. И количество данных, которые используются для обучения, сильно увеличится.
Как продать SSD-диски какому-нибудь гиганту?
В нашей отрасли нельзя просто выпускать SSD и продавать их через магазины.
Расходы на разработку таковы, что продажа в розницу просто не окупается. Чтобы заработать, нужно продать продукт какому-нибудь гиганту. Например, производитель собирается выпустить новый лэптоп и устраивает конкурс среди поставщиков, чтобы выбрать для него SSD. Причём устройства должны быть именно с теми характеристиками, которые указаны в спецификации, не лучше и не хуже. И нам необходимо попасть в заданные рамки: производительность в разных режимах, надёжность, ёмкость и пр.
SSD проходят достаточно жёсткое закрытое тестирование у заказчика: их «жарят» и «морозят» в печах, специально предназначенных для отработки температурных режимов, читают и записывают большие объёмы данных, многократно отключают и вновь включают питание, проверяют соответствие спецификации. Всё это длится минимум месяц.
О том, что именно с нашими накопителями делают, мы обычно не знаем — тесты никто не раскрывает.
Самый сложный момент: тебе принесли «трупик» диска, как именно над ним надругались — не сказали, нужно понять, в чем проблема и исправить её. Для этого нужно быть не только башковитым, но и иметь крепкие нервы: срок на исправление проблемы ограничен, а простыми они не бывают. А ещё — именно решение таких проблем даёт совершенно фантастический драйв.
Кто же такой «фирмварщик»?
Firmware-инженер — это программист, работающий с микроконтроллерами. Он не три метра ростом, у него нет копыт и рогов, он не дышит огнём, разве что иногда.
Но «фирмварщик» взаимодействует с драйверами и с самим «железом», поэтому у него должны быть навыки работы с электроникой, в идеале — опыт её проектирования и глубокое понимание логики работы устройств, того, как происходит взаимодействие на сигнальном уровне. Это не является необходимым условием для написания кода. Но для того, чтобы код был хорошим, не лишним будет понимать, что творится «под капотом».
Если софт зашит в устройство, то поиск в нём ошибок и отладка затрудняются.
Поэтому у нас значительная часть тестов крутится на симуляторе (разработкой которого занимается команда Software Quality Engineering), так ведь проще — больше доступа «в кишочки», любую проблему можно воспроизвести столько раз, сколько необходимо. Но далеко не всё можно воспроизвести в симуляции — многое отлаживается непосредственно «на железе». И тут начинается веселье. Например, записать лог происходящего — уже проблема. Свободной памяти совсем немного, а чтобы надёжно сложить лог в NAND-память надо, по сути, написать независимую от проверяемой прошивки функцию записи. А это, в итоге, выливается в небольшой самостоятельный продукт. При этом с подключенным отладчиком или записью лога проблема может и вовсе не воспроизвестись.
Разработка flash-накопителя достаточно большой и трудоёмкий проект. Только в прошивку вкладывается 50 и более человеко-лет, а еще не менее сложная разработка контроллера, NAND и программных инструментов. Причём в силу специфики NAND-памяти код этот непрост: чтение/запись идут параллельно в несколько потоков, износ нужно «размазывать» по всем ячейкам NAND равномерно, большие усилия тратятся на поддержание целостности данных: из-за миниатюризации ячеек нежелательные «утечки» заряда — это не ошибка, а рабочий момент. В результате помимо пользовательских данных необходимо хранить таблицы размещения блоков, счётчики износа, коды коррекции ошибок и много чего ещё.
И вот, пытаясь сделать устройство немного быстрее, вы начинаете держать часть этих данных в оперативной памяти, постепенно записывая в NAND. Тут приходит «бабушка Клава» и выдёргивает вилку из розетки. Культурно это называется Sudden Power Off — Внезапная Потеря Питания. Естественно, подразумевается возможность «воскреснуть» после такой процедуры, да ещё и потерять только те данные, которые протокольная спецификация позволяет потерять. Время, выделенное на воскрешение, также ограничено спецификацией, трёх дней нет.
Несмотря на то, что производство «флэшек» — бизнес очень дорогой (компаний, которые производят собственный NAND, в мире нет и десятка), конкуренция жёсткая. Она идёт сразу в нескольких измерениях — стоимость, скорость линейной записи, IOPS (количество операций в секунду). Соответственно, идёт постоянная оптимизация — производительности, размера кода, размера используемых данных. Разработчик должен хорошо понимать, во что скомпилируется сишный код прошивки, как располагаются в памяти данные, иметь хорошее представление о структурах данных и алгоритмах. Мы не имеем права кодить, не приходя в сознание.
Исправление ошибок, обнаруженных после выхода в production — отдельная интересная тема для разговора. Теоретически можно выложить новую прошивку. Практически можно более-менее гарантировать её загрузку только в случае enterprise клиента — когда есть какой-то централизованно администрируемый дата-центр, например. Плюс — новая версия прошивки тоже должна пройти квалификационные тесты — это небыстро и недёшево.
Кроме изменяемой части прошивки, есть ещё и ROM-код. Его главная задача — прочитать прошивку из NAND и запустить её. Естественно, ошибка в нём может привести к окончательному «окирпичиванию» устройства, когда потребуется его замена, поэтому эта часть тестируется особенно тщательно.
А если я тоже хочу?
Рынок Firmware-разработки «нетолстый», поэтому найти специалистов сложно. Часто люди приходят в софтверный отдел, изучают там предметную область и переходят к firmware — так проще «втянуться». Софтовые проекты на SFS разрабатываются на С#, С++ и Python. Cама «фирмварь» пишется на чистом С.
Меня часто просят посоветовать, что почитать. Я считаю, что не существует книг, начитавшись которых вы сразу станете хорошим специалистом. Общий постулат «без практики вы никто» применим и здесь. Теория обязательна, но, прочитав книгу о беге, вы не сделаетесь хорошим бегуном. А вот подкреплённый книгами хобби-проект способен очень сильно приблизить вас к цели.
Тем не менее очень рекомендую к прочтению «Искусство программирования» Дональда Кнута, «Язык программирования С» Кернигана и Ритчи, для софтварщиков — «Язык программирования С++» Бьярна Страуструпа. «Дисциплина программирования» Дейкстры определенно скучнее постов на хабре и stackoverflow, но содержит много интересных мыслей.
Из практического материала для «хобби-проектов» — сейчас очень много можно сделать на базе китов на STM32 — они дешевы, доступны и просты в освоении. Вообще, мы с большой охотой берём сильных алгоритмистов, даже если они не имеют представления о железе.
Специфика SFS
Обо всём не рассказать в рамках короткой статьи, но можно остановиться на основном факторе, который определяет выстраивание отношений внутри нашей компании: проекты у нас длятся по году-два (это не время жизни проекта, это время между релизами), срок крепкого вхождения в предметную область на многих позициях — полгода-год. Поэтому мы играем не в короткую, а в длинную: инвестируем в сотрудников, проводим всевозможные курсы — как внутри компании, так и снаружи — хорошему специалисту надо помочь «вызреть».
Ответы на вопросы вы можете получить, написав письмо [email protected], своё резюме присылайте на [email protected].
Фото: Андрей Давыдчик
Материал подготовлен при поддержке компании Softeq Flash Solutions.
Что такое партнёрский материал?
УНП 192263000
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.