Так без скатывания капель по поверхности проблемы не возникает? Т.е. плохо не в общем «побыть автомобилю под дождём», а конкретно под неким объектом, с которого капает, напр. деревом?
Польза этих камер - тоже не нечто абсолютное, не воздух для дыхания. В том обществе вред приватности её перевесил. Возможно, в каком-то другом обществе люди бы с радостью поставили их себе в спальни чтобы там стало больше порядка и закона. Кому что.
Но как тогда вообще классифицировать, "продолжается самоподдерживающаяся цепная реакция" (дословно что предположил академик) или не продолжается? В любой кучке активных атомов будут и спонтанные распады, и некоторая вероятность, что один распад запустит второй, но не на всё из этого скажут "СЦР"?
Поясните, если не сложно? Как неспециалист, наслушавшийся по верхам, тоже всегда представлял, что устойчивая реакция идёт в довольно узком диапазоне параметров, а чуть в сторону - либо затухание, либо разгон и разрушение установки. Нет?
По 1xxx вообще ничего внятного не нашлось, а вот из 2ххх нашёлся MSM2300 и он CDMA/AMPS. С другими цифрами (вторая цифра маркировки и означает стандарт радио, 3-CDMA) ничего не нашлось.
Ещё у Qualcomm самые первые серии SoC MSM1xxx, MSM2xxx были построены на Intel 80186. Позже, начиная с MSM3xxx, уже перешли на ARM, но в квалкомовском диагностическом протоколе как наследие х86 остались команды, зарезервированные под доступ к портам ввода/вывода (у ARM в принципе нет такого понятия).
Однозначно уже прошитая паяется. Для программирования такого «монстра» с пережигаемыми перемычками прямо в системе потребовалась бы куда более серьёзная, чем видно на плате, обвязка (коммутация повышенных напряжений/токов, развязка от остальной системы, чтобы не пережечь заодно и в компе что-нибудь).
Можно, конечно, попробовать пересчитать контрольную сумму или просто запатчить её проверку и посмотреть, что получится. Но как ни крути, оригинал .OBR повреждён (как-то намеренно? копия с ним совпадает) и где это вылезет дальше - вопрос. По-хорошему нужно «разматывать» зашифрованный код, внедряемый в защищаемые .ехе, смотреть, что он делает, гонять с платой, искать, что не сходится.
Используйте .obr файл размера как исходный, но с одними нулями. Такое проходит проверку. Но вообще там да, контрольная сумма. Старый досовский unpklite отлично распаковывает этот софт, дальше он сам по себе никак не защищён. А вот тот код, который он вставляет в защищаемый ехе, частично зашифрован, и расшифровка в лучших традициях тех времён - через перехват прерывания трассировки.
Да, выглядело как будто бы часть команд (самые простые вроде чтения OCR/CID/CSD) обрабатывается прямо железом, их софтовые обработчики пустые. Подозреваю, команда STOP TRANSMISSION обрабатывается и аппаратно (сразу тормозит передачу данных на ММС интерфейсе), и дальше софтово (отмена текущей операции везде, где нужно - сбросить DMA, вывести NAND в состояние ничегонеделания, ну и собственно выход из цикла обработки очередных секторов). Достоинство такой архитектуры - гибкость, в софте всё-таки проще делать что-то «нелинейное», а вашему проекту, насколько я его понимаю, в будущем гибкость ещё нужнее, чем настоящим eMMC. К примеру, дойдёт дело до экспериментов над Андроидом, понадобится эмуляция RPMB, а там весь протокол - на уровне выше, пакеты с командами/параметрами/статусами внутри данных секторов.
Вдруг пригодится: встроенные контроллеры eMMC, которые смотрел (Phison, Appotech) обрабатывают большинство команд софтово: приняли команду, попали в ISR, там её спарсили, выставили статус на отправку, протранслировали LBA в физический адрес NAND (при этом, возможно, читали NAND, чтобы заглянуть в таблицу трансляции), запустили чтение NAND, дождались готовности, настроили DMA между NAND и MMC интерфейсами, дали старт, и вот только тут пошли данные в сторону ММС хоста, и он всё это терпел. Т.е. тайминг команда-данные заведомо не такой уж жёсткий. Особенно учитывая, что всякие «унылые» QLC NAND могут с первой попытки нормально не прочитаться, потребовать более «агрессивной» коррекции (чтение с разными уровнями Vtt и прочие танцы с бубном), и приличные данные из них вылезут и того позже. Ну и сами контроллеры - отнюдь не гигагерцовые монстры, у них и RAM под всю прошивку не у всех хватает, подгружают overlay’и в процессе (опять же из NAND). Масса неопределённостей в общем, но хоста это как-то устраивает.
Да всё бы хорошо, но в нынешней российской реальности ссылки на опыт других стран почему-то возникают в основном в контексте «гражданам запретили»/«граждан ограничили». При этом в тех же США, на опыт которых так любят ссылаться, есть и запреты другого плана (22 поправка, к примеру), а так же масса всяких интересных разрешений (да хоть 1, 2 поправки), но этот опыт рассматривать, увы, никто не торопится
Здорово, но интересна и архитектура программной/логической стороны: что именно делает каждый из 8192 МК? Просто выводит присланное ему RGB на один светодиод? Или что-то знает и о соседних пикселях и отрабатывает какой-нибудь пиксельный шейдер?
Обычные мастера ещё в нулевых вместо тепловизора пшикали на платы китайским спреем-«инеем» и смотрели где тает
А вот и бенефициары</s>
Так без скатывания капель по поверхности проблемы не возникает? Т.е. плохо не в общем «побыть автомобилю под дождём», а конкретно под неким объектом, с которого капает, напр. деревом?
Польза этих камер - тоже не нечто абсолютное, не воздух для дыхания. В том обществе вред приватности её перевесил. Возможно, в каком-то другом обществе люди бы с радостью поставили их себе в спальни чтобы там стало больше порядка и закона. Кому что.
Но как тогда вообще классифицировать, "продолжается самоподдерживающаяся цепная реакция" (дословно что предположил академик) или не продолжается? В любой кучке активных атомов будут и спонтанные распады, и некоторая вероятность, что один распад запустит второй, но не на всё из этого скажут "СЦР"?
Поясните, если не сложно? Как неспециалист, наслушавшийся по верхам, тоже всегда представлял, что устойчивая реакция идёт в довольно узком диапазоне параметров, а чуть в сторону - либо затухание, либо разгон и разрушение установки. Нет?
По 1xxx вообще ничего внятного не нашлось, а вот из 2ххх нашёлся MSM2300 и он CDMA/AMPS. С другими цифрами (вторая цифра маркировки и означает стандарт радио, 3-CDMA) ничего не нашлось.
Ещё у Qualcomm самые первые серии SoC MSM1xxx, MSM2xxx были построены на Intel 80186. Позже, начиная с MSM3xxx, уже перешли на ARM, но в квалкомовском диагностическом протоколе как наследие х86 остались команды, зарезервированные под доступ к портам ввода/вывода (у ARM в принципе нет такого понятия).
Однозначно уже прошитая паяется. Для программирования такого «монстра» с пережигаемыми перемычками прямо в системе потребовалась бы куда более серьёзная, чем видно на плате, обвязка (коммутация повышенных напряжений/токов, развязка от остальной системы, чтобы не пережечь заодно и в компе что-нибудь).
Можно, конечно, попробовать пересчитать контрольную сумму или просто запатчить её проверку и посмотреть, что получится. Но как ни крути, оригинал .OBR повреждён (как-то намеренно? копия с ним совпадает) и где это вылезет дальше - вопрос. По-хорошему нужно «разматывать» зашифрованный код, внедряемый в защищаемые .ехе, смотреть, что он делает, гонять с платой, искать, что не сходится.
Используйте .obr файл размера как исходный, но с одними нулями. Такое проходит проверку. Но вообще там да, контрольная сумма. Старый досовский unpklite отлично распаковывает этот софт, дальше он сам по себе никак не защищён. А вот тот код, который он вставляет в защищаемый ехе, частично зашифрован, и расшифровка в лучших традициях тех времён - через перехват прерывания трассировки.
"Наша служба и опасна и трудна"</s>
Программатор - для Compute Module 5, а не для полноформатной «малины». На модуле нет 8P8C.
Ну и отдельный вопрос - удобство готового инструмента для массового производства. Вставляй модули один за одним, получай готовые.
Да, выглядело как будто бы часть команд (самые простые вроде чтения OCR/CID/CSD) обрабатывается прямо железом, их софтовые обработчики пустые. Подозреваю, команда STOP TRANSMISSION обрабатывается и аппаратно (сразу тормозит передачу данных на ММС интерфейсе), и дальше софтово (отмена текущей операции везде, где нужно - сбросить DMA, вывести NAND в состояние ничегонеделания, ну и собственно выход из цикла обработки очередных секторов). Достоинство такой архитектуры - гибкость, в софте всё-таки проще делать что-то «нелинейное», а вашему проекту, насколько я его понимаю, в будущем гибкость ещё нужнее, чем настоящим eMMC. К примеру, дойдёт дело до экспериментов над Андроидом, понадобится эмуляция RPMB, а там весь протокол - на уровне выше, пакеты с командами/параметрами/статусами внутри данных секторов.
Вдруг пригодится: встроенные контроллеры eMMC, которые смотрел (Phison, Appotech) обрабатывают большинство команд софтово: приняли команду, попали в ISR, там её спарсили, выставили статус на отправку, протранслировали LBA в физический адрес NAND (при этом, возможно, читали NAND, чтобы заглянуть в таблицу трансляции), запустили чтение NAND, дождались готовности, настроили DMA между NAND и MMC интерфейсами, дали старт, и вот только тут пошли данные в сторону ММС хоста, и он всё это терпел. Т.е. тайминг команда-данные заведомо не такой уж жёсткий. Особенно учитывая, что всякие «унылые» QLC NAND могут с первой попытки нормально не прочитаться, потребовать более «агрессивной» коррекции (чтение с разными уровнями Vtt и прочие танцы с бубном), и приличные данные из них вылезут и того позже. Ну и сами контроллеры - отнюдь не гигагерцовые монстры, у них и RAM под всю прошивку не у всех хватает, подгружают overlay’и в процессе (опять же из NAND). Масса неопределённостей в общем, но хоста это как-то устраивает.
Да всё бы хорошо, но в нынешней российской реальности ссылки на опыт других стран почему-то возникают в основном в контексте «гражданам запретили»/«граждан ограничили». При этом в тех же США, на опыт которых так любят ссылаться, есть и запреты другого плана (22 поправка, к примеру), а так же масса всяких интересных разрешений (да хоть 1, 2 поправки), но этот опыт рассматривать, увы, никто не торопится
А никого не ставить в пример - не вариант?
Ну вот тоже подумалось, что никакой это не GPU, а «драйвер матрицы»
Здорово, но интересна и архитектура программной/логической стороны: что именно делает каждый из 8192 МК? Просто выводит присланное ему RGB на один светодиод? Или что-то знает и о соседних пикселях и отрабатывает какой-нибудь пиксельный шейдер?
«Это просто праздник какой-то!»