Перейти к содержимому
rootmaster

продвинутая утилита для прошивки eeprom

Рекомендуемые сообщения

2yLAO4I.png

и так идея подобной утилиты напрашивалась давно

но реализовать решил только сейчас

общем, в чем суть, есть стандартная утилита flash в openOS, но она просто прошивает файл в основной раздел eeprom

проблема это утилиты в том, что она не стирает eeprom-data что может привести к некорректной работе некоторых программ

аж установить eeprom-data полмолчания, уж подавно нельзя, так что я решил сделать продвинутый вариант программы которая позволяет делать полные дампы eeprom, в файл формата eeprom


команда для установки: mkdir /usr/bin; wget https://raw.githubusercontent.com/igorkll/eepromUtil/main/forOpenOS.lua /usr/bin/eeprom.lua -f

 

формат является обычной серилизованной табличкой содержашей следуюшию информацию

  • основной код
  • данные eeprom
  • label
  • состояния readonly

 

Изменено пользователем rootmaster

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ссылка на программу отсутствует, но это не страшно. Ведь полное копирование EEPROM вместе с меткой, данными и флагом ReadOnly можно выполнить на верстаке.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
11 час назад, eu_tomat сказал:

Ссылка на программу отсутствует, но это не страшно.

Теперь исходный код защищён на отлично!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
В 28.07.2022 в 22:01, eu_tomat сказал:

Ссылка на программу отсутствует, но это не страшно. Ведь полное копирование EEPROM вместе с меткой, данными и флагом ReadOnly можно выполнить на верстаке.

забыл ссылку уставить лол бывает мой косяк, оставил, ну так вот, иногда хотеться выложить файлом чтобы другу отправить

PS. и мог нормально в лс сообщить о отсутствии ссылки? что за хейт? да можно через верстак но это не значит, что программа не нужна

Изменено пользователем rootmaster

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
4 часа назад, rootmaster сказал:

и мог нормально в лс сообщить о отсутствии ссылки?

Я вообще думал, что ты создал эту тему ради шутки. Как-то слишком удачно тут совпало отсутствие ссылки на программу с отсутствием потребности в ней. А фраза "идея подобной утилиты напрашивалась давно" ещё более усилила атмосферу абсурда.

 

4 часа назад, rootmaster сказал:

что за хейт?

Хейтом принято называть открытое эмоциональное выражение ненависти, враждебности, злости. Собственно, английское слово хейт и означает ненависть. А что называешь хейтом ты?

 

Но раз тема не шуточная, можно обсудить её по существу:

В 28.07.2022 в 16:11, rootmaster сказал:

есть стандартная утилита flash в openOS, но она просто прошивает файл в основной раздел eeprom

проблема это утилиты в том, что она не стирает eeprom-data что может привести к некорректной работе некоторых программ

аж установить eeprom-data полмолчания, уж подавно нельзя

Мне не приходилось сталкиваться с подобным. Приведи примеры программ, работающих некорректно из-за сохранения старых данных в EEPROM. И каким программам требуются данные по умолчанию?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Напомню, что есть /dev/eeprom и /dev/eeprom-data. С тех пор, как эти файлы реализовали в OpenOS, надобность в утилите flash отпала совершенно.

# cat bios.lua > /dev/eeprom
# echo > /dev/eeprom-data
# cat /dev/eeprom > bios.lua

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
39 минут назад, Fingercomp сказал:

Напомню, что есть /dev/eeprom и /dev/eeprom-data. С тех пор, как эти файлы реализовали в OpenOS, надобность в утилите flash отпала совершенно.

Интересная возможность. А можно ли с помощью подобного функционала задать метку EEPROM?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
3 часа назад, eu_tomat сказал:

А можно ли с помощью подобного функционала задать метку EEPROM?

# echo "Some Label" >/dev/components/by-type/eeprom/0/label

#########################################################

# # весь интерфейс EEPROM

# ls /dev/components/by-type/eeprom/0/label
address   contents  dataSize  label         size type
checksum  data      device    makeReadonly  slot

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
7 часов назад, eu_tomat сказал:

Но раз тема не шуточная, можно обсудить её по существу:

Мне не приходилось сталкиваться с подобным. Приведи примеры программ, работающих некорректно из-за сохранения старых данных в EEPROM. И каким программам требуются данные по умолчанию?

чужим софтом не пользуюсь, но с подобной ситуацией сталкивался, прошивая один из моих биосов после lua bios он крашился, так как в eeprom-data был адрес загрузочного диска, а биос ожидал там увидеть адрес монитора, по сути любая программа может работать некорректно если не стереть eeprom-data, да и гораздо удобнее поместить данные в файл, чем занимать драгоценное место в основном разделе eeprom, например если в eeprom-data ожидается сериализованая табличка, то в файл можно сразу поместить пустую табличку "{}"

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
9 часов назад, Fingercomp сказал:

Напомню, что есть /dev/eeprom и /dev/eeprom-data. С тех пор, как эти файлы реализовали в OpenOS, надобность в утилите flash отпала совершенно.


# cat bios.lua > /dev/eeprom
# echo > /dev/eeprom-data
# cat /dev/eeprom > bios.lua

 

ну... принципе да, но у меня пару раз бинарные данные при чтении из /dev/eeprom бились!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Данные EEPROM, конечно, полезны. Но зачем хранить их вместе с прошивкой, если они содержат уникальные, практически не повторяющиеся адреса?

В 02.08.2022 в 06:45, rootmaster сказал:

иногда хотеться выложить файлом чтобы другу отправить

Тем более, какой смысл переносить данные с уникальными адресами на другой сервер? Достаточно было бы добавить в утилиту прошивки опцию, запрашивающую очистку данных, если очень нужно. Но нужно ли?

В 02.08.2022 в 18:50, rootmaster сказал:

чужим софтом не пользуюсь, но с подобной ситуацией сталкивался, прошивая один из моих биосов после lua bios он крашился, так как в eeprom-data был адрес загрузочного диска, а биос ожидал там увидеть адрес монитора, по сути любая программа может работать некорректно если не стереть eeprom-data

Ты же совсем недавно пропагандировал следование стандартам. А стандартная прошивка Lua BIOS успешно справляется с некорректными данными в EEPROM. И не просто справляется, а сама корректирует неверные данные. То есть, проблемы нет. Или от следования стандартам ты уже отказался?

 

Опцию защиты от записи, пожалуй, можно было бы и добавить в утилиту прошивки. Но какой смысл хранить это состояние в файле вместе с прошивкой? Решение о защите должен принимать игрок, исходя из его текущих потребностей, а не автор прошивки. Автор может лишь рекомендовать установить защиту, указав соответствующий флаг в строке запуска утилиты.

 

Метку EEPROM можно задать опцией командной строки с помощью стандартной утилиты. А учитывая, что для прошивки всё равно требуется запустить командную строку, то не составляет никакой проблемы добавить метку в неё, а не в файл прошивки.

 

Похожая история однажды приключилась и со мной. Я тоже модифицировал утилиту flash и тоже выдумал свой формат, который, к слову, был полностью совместим со стандартной утилитой. В тот раз я поставил задачу хранить метку в одном файле с прошивкой. Это позволило мне быстро (с интервалом примерно в 2 ммнуты) создавать новые версии прошивок и при этом легко ориентироваться в содержимом инвентаря.

 

Стандартную утилиту я успешно модифицировал, решение работало, но я посчитал его неудачным. Для моей специфической одноразовой цели проще оказалось хранить в одном файле с прошивкой не только метку, но и примитивный прошивальщик. А для широкого применения моя модификация оказалась и вовсе бесполезной, учитывая уже имеющийся функционал стандартной утилиты.

 

Что можно сделать с утилитой из этой темы? В первую очередь я рекомендую обеспечить совместимость формата со стандартной утилитой. Это поднимет шанс того, что её начнёт использовать кто-то кроме автора. Может быть, кому-то и вправду потребуется хранить всё это в одном файле с прошивкой. Интересно будет узнать об этих случаях и потом сравнить удобство стандартной и модифицированной утилиты.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
8 минут назад, eu_tomat сказал:

Данные EEPROM, конечно, полезны. Но зачем хранить их вместе с прошивкой, если они содержат уникальные, практически не повторяющиеся адреса?

Тем более, какой смысл переносить данные с уникальными адресами на другой сервер? Достаточно было бы добавить в утилиту прошивки опцию, запрашивающую очистку данных, если очень нужно. Но нужно ли?

ты же понимаешь что данные в eeprom-data могут быть любые? если бы не столь маленький лимит eeprom то да, можно в код захардкодить коррекцию неправильных данных, но а в друг мне нужно часть кода поместить прямо в eeprom-data дабы сэкономить место?

 

там могут быть не только адреса, но и настройки биос, уже приводил пример, но приведу еще раз, там может быть таблица "{}" или даже уже забитая данными "{password = '222', oemUnlock = false, oemUnlockAllow = true}" и в код это может банально не влезть

 

цель дынной утилиты, создать максимально точный слепок eeprom для последующей передачи, или хранения

 

8 минут назад, eu_tomat сказал:

Что можно сделать с утилитой из этой темы? В первую очередь я рекомендую обеспечить совместимость формата со стандартной утилитой. Это поднимет шанс того, что её начнёт использовать кто-то кроме автора. Может быть, кому-то и вправду потребуется хранить всё это в одном файле с прошивкой. Интересно будет узнать об этих случаях и потом сравнить удобство стандартной и модифицированной утилиты.

ну... могу разве что pull-request кинуть, но вряд ли его кто-то примит

 

6 минут назад, eu_tomat сказал:

Ты же совсем недавно пропагандировал следование стандартам. А стандартная прошивка Lua BIOS успешно справляется с некорректными данными в EEPROM. И не просто справляется, а сама корректирует неверные данные. То есть, проблемы нет. Или от следования стандартам ты уже отказался?

я пропагандировал, следования внешним стандартам общения между биос и ос, но я не против их дополнения, так например при использовании microbios, computer.shutdown("bios") перезагрузит тебя прямо в меню bios а computer.shutdown("fast") перезагрузит минуя вход в меню биос(тебе не предложит его открыть), однако если у ОС своя прошивка eeprom и не предполагается установка нечего костюмного то в особых случаях, как например зашишенная ос, стандартами можно пренебречь

Изменено пользователем rootmaster

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
39 минут назад, rootmaster сказал:

могу разве что pull-request кинуть, но вряд ли его кто-то примит

Как думаешь, почему так мало шансов на принятие?

 

40 минут назад, rootmaster сказал:

ты же понимаешь что данные в eeprom-data могут быть любые?

Ты же понимаешь, что данные на то и данные, что зависят от конкретных условий и могут меняться? А если эти данные могут меняться в процессе работы, то что мешает в процессе же работы их и сформировать?

5 часов назад, rootmaster сказал:

там могут быть не только адреса, но и настройки биос, уже приводил пример, но приведу еще раз, там может быть таблица "{}" или даже уже забитая данными "{password = '222', oemUnlock = false, oemUnlockAllow = true}" и в код это может банально не влезть

И эти данные никогда не меняются иначе как со сменой прошивки?

 

5 часов назад, rootmaster сказал:

но а в друг мне нужно часть кода поместить прямо в eeprom-data дабы сэкономить место?

Вот тут соглашусь, я и сам таким баловался. Правда, в том случае в первую очередь использовалось сжатие кода, т.к именно оно обеспечивало максимальную экономию памяти, поэтому чтение из области данных EEPROM возлагалось на распаковщик, а запись в EEPROM — на упаковщик. Заметной прибавки это решение не давало, порядка 5%, но поиграться с дополнительной памятью было увлекательно.

 

Если сейчас мы с тобой говорим об одном и том же, то речь всё-таки идёт о специализированной утилите под конкретную задачу. Но тогда сравнение со стандартной утилитой flash становится неуместным, потому как она предназначена для широкого круга более-менее стандартных задач, а твою утилиту я бы даже не стал как-то отделять от пакета программ упаковки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 час назад, eu_tomat сказал:

Ты же понимаешь, что данные на то и данные, что зависят от конкретных условий и могут меняться? А если эти данные могут меняться в процессе работы, то что мешает в процессе же работы их и сформировать?

банально может не хватить места для этого, а нужно же еще как-то чекать валидность данных, больше, нечего не мешает, но все равно задать данные по умолчанию проше, и на мой взгляд более правильно и элегантно

 

1 час назад, eu_tomat сказал:

И эти данные никогда не меняются иначе как со сменой прошивки?

могут меняться

могут нет

могут меняться, но не все

да и иногда хочется например, передать другу не шарющему, уже настроенный биос где уже все готого к работа

1 час назад, eu_tomat сказал:

Вот тут соглашусь, я и сам таким баловался. Правда, в том случае в первую очередь использовалось сжатие кода, т.к именно оно обеспечивало максимальную экономию памяти, поэтому чтение из области данных EEPROM возлагалось на распаковщик, а запись в EEPROM — на упаковщик. Заметной прибавки это решение не давало, порядка 5%, но поиграться с дополнительной памятью было увлекательно.

5% уже могут за решать, но основной замысел, все-же будет задать дынные по умолчанию, если утилита flash шьет только сам скрипт, то утилита eeprom целый образ

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
12 часа назад, rootmaster сказал:

банально может не хватить места для этого, а нужно же еще как-то чекать валидность данных

Учитывая твоё стремление к максимальному увеличению функциональности прошивок, я предполагаю, что ты постараешься использовать все доступные возможности для сжатия. И раз ты уже начал использовать область данных, то следующим шагом будет сжатие обоих кусков EEPROM как одного большого куска. Просто потому, что такое сжатие будет более эффективным. Но такое развитие возвращает нас к специализированной утилите, упаковывающей код в EEPROM.

 

Но, предположим, ты всё-таки не будешь сжимать блок данных:

13 часа назад, rootmaster сказал:

все равно задать данные по умолчанию проше, и на мой взгляд более правильно и элегантно

...

могут меняться, могут нет, могут меняться, но не все

Да, существование ПО, параметры которого заданы извне, вполне возможно. Но в таких случаях к самому ПО прилагается и дополнительная утилита, обрабатывающая все необходимые проверки и умолчания. Также эту задачу зачастую перекладывают на документацию, текстовый редактор и голову системного администратора, такой подход тоже может быть удобным. Но применительно к обсуждаемой утилите он как раз неудобен из-за объединения в одном файле блока параметров с блоком кода, что усугубляется двоичным представлением сжатого кода. И это снова возвращает нас к специализированной утилите, написанной под конкретную задачу.

 

14 часа назад, rootmaster сказал:

иногда хочется например, передать другу не шарющему, уже настроенный биос где уже все готого к работа

Другу потребуется выполнить следующие действия: скачать твою утилиту прошивки, скачать файл прошивки, скопировать строку запуска утилиты. А если всё это делать без твоей утилиты, то потребуется: скачать файл прошивки, скачать файл параметров (если требуется), скопировать строку, заполняющую код и данные EEPROM. В принципе, все эти три действия можно объединить в одну строку. Но в любом случае второй подход создаёт меньший трафик в сети и увеличивает надёжность за счёт исключения лишнего звена.

 

13 часа назад, rootmaster сказал:

если утилита flash шьет только сам скрипт, то утилита eeprom целый образ

Это я понял. Только я не вижу тут универсального применения в отличие от утилиты flash. Пока я вижу лишь специальные случаи, в которых применение универсальной утилиты не даёт никаких преимуществ. Твоя утилита, конечно, имеет право на существование, но, скорее, как экзотика для гурманов, а не замена стандартной утилите.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
31 минуту назад, eu_tomat сказал:

Это я понял. Только я не вижу тут универсального применения в отличие от утилиты flash. Пока я вижу лишь специальные случаи, в которых применение универсальной утилиты не даёт никаких преимуществ. Твоя утилита, конечно, имеет право на существование, но, скорее, как экзотика для гурманов, а не замена стандартной утилите.

ну да, софт не универсальный

 

31 минуту назад, eu_tomat сказал:

Учитывая твоё стремление к максимальному увеличению функциональности прошивок, я предполагаю, что ты постараешься использовать все доступные возможности для сжатия. И раз ты уже начал использовать область данных, то следующим шагом будет сжатие обоих кусков EEPROM как одного большого куска. Просто потому, что такое сжатие будет более эффективным. Но такое развитие возвращает нас к специализированной утилите, упаковывающей код в EEPROM.

я думаю, что смогу сам написать арефмо кодер, и в скором времени этим займусь

 

32 минуты назад, eu_tomat сказал:

Другу потребуется выполнить следующие действия: скачать твою утилиту прошивки, скачать файл прошивки, скопировать строку запуска утилиты. А если всё это делать без твоей утилиты, то потребуется: скачать файл прошивки, скачать файл параметров (если требуется), скопировать строку, заполняющую код и данные EEPROM. В принципе, все эти три действия можно объединить в одну строку. Но в любом случае второй подход создаёт меньший трафик в сети и увеличивает надёжность за счёт исключения лишнего звена.

ладно, признаю, пример с нешарюшим другом плохой

33 минуты назад, eu_tomat сказал:

Да, существование ПО, параметры которого заданы извне, вполне возможно. Но в таких случаях к самому ПО прилагается и дополнительная утилита, обрабатывающая все необходимые проверки и умолчания. Также эту задачу зачастую перекладывают на документацию, текстовый редактор и голову системного администратора, такой подход тоже может быть удобным. Но применительно к обсуждаемой утилите он как раз неудобен из-за объединения в одном файле блока параметров с блоком кода, что усугубляется двоичным представлением сжатого кода. И это снова возвращает нас к специализированной утилите, написанной под конкретную задачу.

ну... проблема таких утилит в том, что они идут под api конкретной ос, а вдруг у меню другая ос?

а утилиту eeprom под нее будет портировать куда проще, чем сотню другую утилит, существующих только для того, чтобы прошить один конкретный захардкоженный в них образ

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, rootmaster сказал:

проблема таких утилит в том, что они идут под api конкретной ос, а вдруг у меню другая ос?

Для реализации кроссплатформености потребуется придумать какой-то стандарт хранения данных и в дальнейшем следовать ему. Данные в EEPROM могут храниться хоть в текстовом, хоть в двоичном виде. Но хранение файла конфигурации в виде текста способно обеспечить высокий уровень кроссплатформенности с минимальными накладными расходами. Игрок может скорректировать файл конфигурации, воспользовавшись любимым текстовым редактором, а затем твоя утилита считает данные из файла, приведёт информацию к более компактному виду и запишет данные в EEPROM. Главное, в каждом конкретном случае дать игроку внятную документацию, объясняющую, что даёт изменение того или иного параметра, и каковы их рабочие пределы. Я знаю два эффективных текстовых формата в среде Lua: это либо формат сериализованной таблицы, либо это обычный код на Lua. Второй формат обеспечивает лучшую производительность и гибкость.

 

Дав пользователю возможность отделить данные от кода в тех случаях, когда они и так фактически разделены, ты можешь сделать свою утилиту более полезной. Она, может, и не станет настолько же универсальной как flash из OpenOS, но хотя бы обеспечит большее удобство решения какого-то круга задач.

 

4 часа назад, rootmaster сказал:

утилиту eeprom под нее будет портировать куда проще, чем сотню другую утилит, существующих только для того, чтобы прошить один конкретный захардкоженный в них образ

Это верно. В дальней перспективе имеет смысл разрабатывать удобные универсальные программы, способные заменить кучу других программ. Только нужно иметь в виду, что абсолютно универсальных инструментов не существует, а для достижения подобия универсальности мы по сути придумываем технологию, некий стандарт, в который потом пытаемся втиснуть решаемые задачи. И тогда стандарт может начать работать не только на нас, но и против нас.

 

Например, ты мне прислал файл прошивки вместе с данными, а я эти данные скорректировал под свои нужды. Затем ты исправил ошибку в прошивке и снова выслал мне файл, в котором я вынужден ещё раз корректировать эти данные, хотя я бы предпочёл иметь возможность просто выбрать файл с нужными мне данными во время прошивки. Это пример затруднений для пользователя.

 

Но затруднения от поспешно принятого стандарта возникают и у разработчика. Не знаю, как это работает у тебя, но мне обычно требуется решить хотя бы 5 похожих задач, что начать серьёзно думать над какими-то стандартами их решения. Первые мысли появляются уже при решении второй задачи, но это просто мысли. Максимум, что полезного можно сделать с ними — просто записать на будущее. Но реализовывать их я обычно не спешу. Можно, конечно, поспешить, но тогда при решении очередной задачи старые стандарты потребуется корректировать. А это уже дополнительный объём работы. А если ты ранее смог убедить других программистов использовать свой стандарт, то и они будут вынуждены приложить усилия, чтобы переписать свой код под новые требования.  Стандарты призваны облегчать работу, а не затруднять её.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в тему...

×   Вы вставили отформатированное содержимое.   Удалить форматирование

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.


×
×
  • Создать...