Кастомные прошивки и техническая часть устройств Joyetech, Wismec, Eleaf, Vaporflask

JAW Я там пока правил ровную прошивку для эвика 3.02, наваял патчик на координаты основного вывода на экран... выводов значков "W" уже насчитал 32 раза :D

---------- Сообщение отправлено в 23:16 ---------- Предыдущее сообщение отправлено в 23:12 ----------

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

И еще при этом вопрос - какой максимальный размер прошивки?

Цитата:

---

Сообщение от MicroSur

Кстати для патчеров предложение, новые патчи выносить за пределы прошивки сразу, отделяя для них какое то пространство, с определенного адреса.

---

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

Цитата:

---

Сообщение от MicroSur

Возможно это поможет избежать конфликтов и порчи "прошивочной графики", которую уже используют по другому.

---

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

Цитата:

---

Сообщение от MicroSur

И еще при этом вопрос - какой максимальный размер прошивки?

---

Теоретический максимальный размер 0х19000 или же 100кб. Именно начиная с 0х19000 происходит запись "кастомных" лого от производителя.
Однако мы не можем утверждать наверняка, что оставшееся свободное место в этом диапазоне никак не используется.

Пока вижу, что резервирование места под патч в прошивке носит характер "от балды".
Попытался тут расширить патч подсветки на инверсию - фиг, место уже занято другим патчем.
Естественно, что производитель может вставить палки в любой момент, волков бояться - патчи не писать (и редакторы тоже).

Не знаю, туда ли выкладываю, но вот патчи на айстик 100 и рыксу, под последние прошивки. Оба патча делают только одно — изменение мощности идёт по одному ватту, без десятых.
iStick 100TC, 1.10
RX200, 3.10

Цитата:

---

Сообщение от MicroSur

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

---

А пока пачти не будут в перемещаемом формате - так и будет.
Я вот тут в теме другой кухни излагал идеи о таком формате, но народ не проникся.
Может в своем VTCFont реализуете ? Алгоритм как считаются адреса Вам вроде бы уже объясняли.

Цитата:

---

Сообщение от TrusovIgor

Я вот тут в теме другой кухни излагал идеи о таком формате, но народ не проникся.

---

Народ проникся и искренне желает заиметь такой функционал. Вопрос в его цене...

Цитата:

---

Сообщение от TrusovIgor

Алгоритм как считаются адреса Вам вроде бы уже объясняли.

---

Вы забываете одну очень важную вещь - патч это последовательность изменения байт с оригинала на новые значение.
Ассемблерные команды это другой уровень. Что бы была возможно реализовать то, что вы предлагает нужно написать свой компилятор ARM9, который будет на лету компилировать патч(асм-код, попутно рассчитывая все сдвиги) в байткод, и только потом уже применять.

Цитата:

---

Сообщение от TrusovIgor

Алгоритм как считаются адреса Вам вроде бы уже объясняли.

---

По моему ты советуешь написать свой дизассемблер.

Цитата:

---

Сообщение от MicroSur

По моему ты советуешь написать свой дизассемблер.

---

Не дизаассемблер, а ассемблер. И только в той части которая касается пересчета адресов.
Сами команды как были так и остаются. В Командах используется либо адрес в лоб(не уверен что у арма есть такой режим) либо смещения от текущего места. И это смещение занимает вполне определенные места. Их и надо менять.
Зато конфликтов места для пачта не будет.
А писать - да муторно. И для перевода патча в новый формат надо будет писать приладу. Полуавтоматическую. Которой надо будет указать в каких местах патча адреса.

В принципе, насколько понимаю, можно же сделать и абсолютный переход.
MOV PC, ....
В PC ж по логике должен быть абсолютный адрес?

Правда так подпрограмму не сделать, т.к. BL ещё и адрес возврата в LR сохраняет, при этом возврат MOV PC, LR

Цитата:

---

Сообщение от JAW

В принципе, насколько понимаю, можно же сделать и абсолютный переход.

---

Если вы про мои предложения - то я такого даже в мыслях не имел.
Патчи как писались так и должны писаться. Мое предложение о том что они должны по другому оформляться и применяться.

TrusovIgor
Нет, не о твоём. Там одна из проблем в том, что адресация относительная, т.е. не выделить вот так, что с этого адреса мой патч, и он всегда с этого адреса, нужно просто на него переправить не выйдет. Нужно посчитать до него смещение.

Цитата:

---

Сообщение от JAW

TrusovIgor
Нет, не о твоём. Там одна из проблем в том, что адресация относительная, т.е. не выделить вот так, что с этого адреса мой патч, и он всегда с этого адреса, нужно просто на него переправить не выйдет. Нужно посчитать до него смещение.

---

Ну я предлагаю прямо противоположное. Оформлять патчи так, что бы адрес для патча определял исключительно патчер. И патчер бы считал и проставлял смещения. В конце концов патчер этол программа, чего бы ей не посчитать :). А патчерописатель бы указывал в патче место куда эти смещения записать надо(ну и абсолютные адреса для этих смещений). Типа в это слово записать смещение на МойКод+12. А в это слово моего кода смещение на абсолютный адрес такой-то.

Цитата:

---

Сообщение от TrusovIgor

А пока пачти не будут в перемещаемом формате - так и будет.
Я вот тут в теме другой кухни излагал идеи о таком формате, но народ не проникся.

---

А вы попробуйте партировать хоть один патч, и поймете почему не проникся... например по мимо адресов могут измениться адреса датафлэш где хранятся нужные данные... если патч меняет скажем время гашения экрана (3 раза по одной строке в разных местах), то его не переместить автоматом, потому что подобных кусков кода может быть много больше чем надо, а если патч сложный то помимо расчета адресов встанет вопрос, а на старом ли месте лежат данные нужные... а иногда и вобще функционал меняется, например 2-5 click там был добавлен обработчик Fire + , а теперь эта комбинация используется и есть в стоке...

Цитата:

---

Сообщение от yii

А вы попробуйте партировать хоть один патч, и поймете почему не проникся... например по мимо адресов могут измениться адреса датафлэш где хранятся нужные данные... если патч меняет скажем время гашения экрана (3 раза по одной строке в разных местах), то его не переместить автоматом, потому что подобных кусков кода может быть много больше чем надо, а если патч сложный то помимо расчета адресов встанет вопрос, а на старом ли месте лежат данные нужные... а иногда и вобще функционал меняется, например 2-5 click там был добавлен обработчик Fire + , а теперь эта комбинация используется и есть в стоке...

---

Ни один формат патчей не спасет от этой работы. Облегчит или нет - и то спорный вопрос. Но вот этого:

Цитата:

---

Сообщение от MicroSur

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

---

точно не будет.
А выкидывание второго блока шрифтов(точнее запись двух вариантов прошивки) даст и возможность выставлять произвольному глифу произвольный размер и исчезнет вопрос:

Цитата:

---

Сообщение от MicroSur

И еще при этом вопрос - какой максимальный размер прошивки?

---

Потому как расширять не потребуется. Ну а для тех модов где блок один - там да, только расширять или урезать размер у мусорных глифов. Исходя из того, что когда понадобится - можно и расширить.

Что если:
1. Низвести все патчи до состояния врезок, т.е. в родной прошивке делать переход на тело патча, потом обратно. - тем самым минимизировать изменения в родном мясе.
2. Все врезки писать за границей родной прошивки в формате: PATCH ID, PATCH SIZE, PATCH BODY, <PATCH ID, PATCH SIZE, PATCH BODY, >..<>..<>.. и т.д.
Тогда:
1. Все патчи живут в своем месте и не путаются друг с другом, за исключением тех случаев, когда место врезания одинаково
2. Вносят минимум правок в оригинальный код - делается лишь переход за границы родной прошивки на тело патча
3. Если патч работает с ресурсами (лого/спец символы) - прикладывать к патчу ресурсник

Цитата:

---

Сообщение от djnightrider

Низвести все патчи до состояния врезок, т.е. в родной прошивке делать переход на тело патча, потом обратно. - тем самым минимизировать изменения в родном мясе.

---

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

Цитата:

---

Сообщение от djnightrider

Все врезки писать за границей родной прошивки в формате: PATCH ID, PATCH SIZE, PATCH BODY, <PATCH ID, PATCH SIZE, PATCH BODY, >..<>..<>.. и т.д.

---

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

Цитата:

---

Сообщение от djnightrider

Все патчи живут в своем месте и не путаются друг с другом, за исключением тех случаев, когда место врезания одинаково

---

То есть это никак не помогает, потому что часто врезаться можно только в одном месте, отсюда и несовместимость с другими патчами.

Цитата:

---

Сообщение от djnightrider

Вносят минимум правок в оригинальный код - делается лишь переход за границы родной прошивки на тело патча

---

Так и есть. Код редко кто корёжит, корёжат данные.

Цитата:

---

Сообщение от djnightrider

Если патч работает с ресурсами (лого/спец символы) - прикладывать к патчу ресурсник

---

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

Цитата:

---

Сообщение от djnightrider

в родной прошивке делать переход на тело патча, потом обратно.

---

Как я понимаю патчи со врезками так и работают. А если в патче нужно пару байт поправить - так даже места на переход нету.

Цитата:

---

Сообщение от djnightrider

1. Низвести все патчи до состояния врезок, т.е. в родной прошивке делать переход на тело патча, потом обратно. - тем самым минимизировать изменения в родном мясе.

---

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

Иэх. Понял.
Пячаль.

Я просто за чистоту бананов :)
У них в сумме места чуть больше, чем на заставку 64х40, а код E3 оставить на полноэкранный "скринсейвер".
Поглядев на сайт с кастом прошивками, там портят E3 все поголовно, я бы испортил бананы, но они заняты патчами.