Камон, любой желающий может послать любой пакет на мой внешний роутер, потому что кабель к нему идёт через щиток на этаже, там подключаешь свич в разрыв и готово. Там даже переходник мама-мама стоит в разрыве для удобства!
Но даже безотносительно этого, если у вас доступ к памяти через auipc, стартап-код как раз может обеспечить корректность выполняемого кода, передав на него управление по правильному адресу. По тому, который ожидает линкер во время линковки.
Я пока тут не вижу никакого позиционно-независимого кода, вижу только обычный позиционно-зависимый. Тот факт, что код может выполняться из других адресов -- проблема исключительно стартап-кода, он должен сделать так, чтобы остальной код ничего не заметил.
Проблема с li, насколько я понимаю, в том, что компилятор не может её сразу скомпилировать если он не знает адрес метки. А адрес метки неизвестен до линковки. В зависимости от значения адреса нужно сгенерировать или одну инструкцию, или две, поэтому на этапе компиляции просто выдаётся ошибка. Если всё же очень хочется, приходится выписывать вручную li как две инструкции (lui+addi), тогда всё будет ок, но addi в итоге может оказаться лишней.
Под контроллеры же обычно позиционно-независимый код не пишут, и все наши обращения к переменным из Си будут развернуты в тот же la, что сводит смысл от страдания со стартапом на нет.
Есть как минимум два сценария, когда нужен абсолютный адрес, а не относительный:
флеш может располагаться по адресу 0x0800_0000, но выполнение кода происходить по адресу 0. Можно конечно с помощью ld-скрипта разместить код тоже по адресу 0, но тогда прошивка чипа может перестать работать
в чипе могут быть регионы кэшируемой и не кэшируемой памяти, и выполнение может начинаться с не кэшируемой памяти, а потом переходить в кэшируемую в стартапе. До тех пор, пока адрес выполняемой инструкции не будет 100% известен, пользоваться la опасно.
Помимо всего этого когда вы запускаете прошивку под дебаггером, он может начать её выполнять с "правильного" адреса, а потом после ресета микроконтроллер начнёт выполнять её с того, который ему кажется правильным. В общем, загрузка абсолютного адреса позволяет минимизировать проблемы, связанные с особенностями конкретного МК, потому что она работает всегда одинаково.
Пользуюсь промужеточным вариантом: принтер с картриджами, но прозрачными и пополняемыми, которые ещё и умеют сами себе счётчик сбрасывать. Если раньше оригинального картриджа "хватало" на месяц при незначительном объёме печати, то сейчас читерского картриджа "хватает" на полгода, после чего по факту в нём остаётся минимум 2/3 чернил. С учётом бутылочек с чернилами мне этого комплекта хватит ещё на несколько лет.
Проверьте что будет, если камеру засветить так же как в статье, но ещё красным и зелёным лазером. Что-то мне подсказывает, что от матрицы останется совсем немного рабочих пикселей после этого.
Тут у нас другая лаба. Два неймспейса в виртуалке: в одном DHCP-клиент, в другом — DHCP-сервер. Они соединены друг с другом через veth-пару.
Нет ли здесь какого-то подвоха? Будет ли работать предложенное решение с оригинальной постановкой задачи, или нельзя просто так взять и завести XDP в общем случае?
Мне для своего телефона от Xiaomi удалось нагуглить сервисные утилиты для прошивки через EDL, всё в открытом доступе лежало чуть ли не на официальном сайте. Не знаю, правда, какой набор возможностей предоставлял конкретно этот EDL-лоадер, но само существование его в открытом доступе удивило. Может быть вычитать дамп не получится через него, только записать.
Время ожидания влития — это время, когда PR просто висит без правок. Оно считается от времени последнего коммита. Мы можем видеть тут, что часть PR висит в таком состоянии неделю. Т.к. коммитов нет — это не ревью, иначе могли бы быть правки кода. Что же это?
Мне как-то привычнее вносить мелкие правки в последний (часто единственный) коммит. До ревью всё равно никто этого не увидит. Время коммита при этом не обновляется, что создаёт отсутствие видимости работы. И да, время коммита может не соответствовать времени открытия PR, я могу девелопить в локальной ветке долго и нудно, а потом открыть PR. В общем, довольно спорная метрика получилась, но при определённых условиях наверное даже рабочая.
Можно ещё почитать текст по ссылке, которую вы приводите:
Svace – основной анализатор Samsung с 2015 года. Применяется для проверки собственного ПО компании на базе ОС Android и исходного кода ОС Tizen, которая используется в смартфонах, информационно-развлекательных системах и бытовой технике Samsung. С 2017 года Svace проверяет все изменения, присланные для рецензирования и включения в ОС Tizen. C 2020 года Svace применяется также в компании Huawei.
Этот функционал взялся не "вдруг", он довольно давно разрабатывается. Самая ранняя публикация, которую мне удалось найти, датируется вообще 2011 годом.
На другой плате от Sipeed тоже стоял похожий программатор, и какой же он убогий. Мало того, что прошивка идёт через раз, так даже попытка запустить официальный USB Complience Test для эмулируемого FTDI устройства заканчивается аварийным завершением. Попробуйте взять программатор на настоящем FT2232H, с ним должно быть всё ок.
По поводу Synplify: вроде как он там уже давно не работает, даже в с лицензионным ключом мне был доступен только их собственный Gowin Synthesis. Можно проверить в настройках, что из этого используется для синтеза.
Мне кажется, тут не столько возможность восстановления важна, сколько потенциальная возможность внедрить вредоносный код в процесс загрузки, о котором другие клиенты и знать не будут, особенно если этот код крутится на GPU.
Все эти режимы сделаны намеренно и нужны в разных ситуациях.
Так он не фиксирован. Догадываться не надо, в Reference Manual написано про эту память.
Не очень удобно, но исправлено в более новых контроллерах. Впрочем, DMA должен уметь делать такую конвертацию.
Только DTOG_RX для такого endpoint называется SW_BUF, если Reference Manual почитать. А в остальном — почему бы и нет? Поскольку такой endpoint не может одновременно работать на чтение и на запись, часть битов не имеет смысла и может в теории использоваться как угодно.
Интересно, как вы это сделали, если стандарт USB 2.0 приводит максимальную пропускную способность для Bulk и 64-байтных пакетов равную 1216000, что есть 9.728 Mbit/s. Что-то тут не сходится...
Камон, любой желающий может послать любой пакет на мой внешний роутер, потому что кабель к нему идёт через щиток на этаже, там подключаешь свич в разрыв и готово. Там даже переходник мама-мама стоит в разрыве для удобства!
Вероятно у нас какие-то очень разные компиляторы или параметры компиляции, потому что у меня разворачивается в lui:
Но даже безотносительно этого, если у вас доступ к памяти через auipc, стартап-код как раз может обеспечить корректность выполняемого кода, передав на него управление по правильному адресу. По тому, который ожидает линкер во время линковки.
Я пока тут не вижу никакого позиционно-независимого кода, вижу только обычный позиционно-зависимый. Тот факт, что код может выполняться из других адресов -- проблема исключительно стартап-кода, он должен сделать так, чтобы остальной код ничего не заметил.
Проблема с li, насколько я понимаю, в том, что компилятор не может её сразу скомпилировать если он не знает адрес метки. А адрес метки неизвестен до линковки. В зависимости от значения адреса нужно сгенерировать или одну инструкцию, или две, поэтому на этапе компиляции просто выдаётся ошибка. Если всё же очень хочется, приходится выписывать вручную li как две инструкции (lui+addi), тогда всё будет ок, но addi в итоге может оказаться лишней.
Есть как минимум два сценария, когда нужен абсолютный адрес, а не относительный:
флеш может располагаться по адресу 0x0800_0000, но выполнение кода происходить по адресу 0. Можно конечно с помощью ld-скрипта разместить код тоже по адресу 0, но тогда прошивка чипа может перестать работать
в чипе могут быть регионы кэшируемой и не кэшируемой памяти, и выполнение может начинаться с не кэшируемой памяти, а потом переходить в кэшируемую в стартапе. До тех пор, пока адрес выполняемой инструкции не будет 100% известен, пользоваться la опасно.
Помимо всего этого когда вы запускаете прошивку под дебаггером, он может начать её выполнять с "правильного" адреса, а потом после ресета микроконтроллер начнёт выполнять её с того, который ему кажется правильным. В общем, загрузка абсолютного адреса позволяет минимизировать проблемы, связанные с особенностями конкретного МК, потому что она работает всегда одинаково.
Пользуюсь промужеточным вариантом: принтер с картриджами, но прозрачными и пополняемыми, которые ещё и умеют сами себе счётчик сбрасывать. Если раньше оригинального картриджа "хватало" на месяц при незначительном объёме печати, то сейчас читерского картриджа "хватает" на полгода, после чего по факту в нём остаётся минимум 2/3 чернил. С учётом бутылочек с чернилами мне этого комплекта хватит ещё на несколько лет.
Проверьте что будет, если камеру засветить так же как в статье, но ещё красным и зелёным лазером. Что-то мне подсказывает, что от матрицы останется совсем немного рабочих пикселей после этого.
Можно и на микроконтроллере сделать, если постараться: https://github.com/Wren6991/PicoDVI
Подозреваю, что в сервисном центре из платы что-то наоборот выпаяли, поэтому и рекомендовали не ремонтировать.
Нет ли здесь какого-то подвоха? Будет ли работать предложенное решение с оригинальной постановкой задачи, или нельзя просто так взять и завести XDP в общем случае?
А, ну тут статическую ARP запись нужно добавить. С такой схемой настройки всё и через IPv6 должно работать, как мне кажется.
С каких пор WoL стал работать по IPv4?
Мне для своего телефона от Xiaomi удалось нагуглить сервисные утилиты для прошивки через EDL, всё в открытом доступе лежало чуть ли не на официальном сайте. Не знаю, правда, какой набор возможностей предоставлял конкретно этот EDL-лоадер, но само существование его в открытом доступе удивило. Может быть вычитать дамп не получится через него, только записать.
Мне как-то привычнее вносить мелкие правки в последний (часто единственный) коммит. До ревью всё равно никто этого не увидит. Время коммита при этом не обновляется, что создаёт отсутствие видимости работы. И да, время коммита может не соответствовать времени открытия PR, я могу девелопить в локальной ветке долго и нудно, а потом открыть PR. В общем, довольно спорная метрика получилась, но при определённых условиях наверное даже рабочая.
Можно ещё почитать текст по ссылке, которую вы приводите:
Этот функционал взялся не "вдруг", он довольно давно разрабатывается. Самая ранняя публикация, которую мне удалось найти, датируется вообще 2011 годом.
На другой плате от Sipeed тоже стоял похожий программатор, и какой же он убогий. Мало того, что прошивка идёт через раз, так даже попытка запустить официальный USB Complience Test для эмулируемого FTDI устройства заканчивается аварийным завершением. Попробуйте взять программатор на настоящем FT2232H, с ним должно быть всё ок.
По поводу Synplify: вроде как он там уже давно не работает, даже в с лицензионным ключом мне был доступен только их собственный Gowin Synthesis. Можно проверить в настройках, что из этого используется для синтеза.
Мне кажется, тут не столько возможность восстановления важна, сколько потенциальная возможность внедрить вредоносный код в процесс загрузки, о котором другие клиенты и знать не будут, особенно если этот код крутится на GPU.
А требования "пользователь не должен иметь возможность запороть EEPROM/процесс загрузки" у вас нет?
Интересно, как вы это сделали, если стандарт USB 2.0 приводит максимальную пропускную способность для Bulk и 64-байтных пакетов равную 1216000, что есть 9.728 Mbit/s. Что-то тут не сходится...
Упоминался вскользь, зато аж в двух докладах!