Перейти к содержимому
Калькуляторы

PaulFertser

Пользователи
  • Публикации

    6
  • Зарегистрирован

  • Посещение

Все публикации пользователя PaulFertser


  1. Ничего не буду делать, найду что-нибудь более вменяемое, уж железку для себя купить мне не проблема. Признаю, был не прав. Спасибо за совет, но я уж как-нибудь просто пересоберу с отключенным по умолчанию eth1, потому что в остальном эта тухлятина работает не хуже, чем от нее ожидается, для нашей лаборатории вполне сойдет. Спасибо за прошивку. Happy hacking!
  2. А вот остальные смогли. Вопрос - ЧОДНТ ? =) Достаточно. Тут всё банально, загрузитесь с отключенным кабелем и полегчает. Пробовал, и не раз. И сейчас попробовал -- не полегчало, все равно намертво виснет. И я не думаю, что кто-то использует сколько-нибудь современные wive-ng на g700ap, по крайней мере google мне про таких не рассказывал. Я вот не хочу сечас опять браться и просматривать всё это дело. Но я собираю ровно из тех же сырцов и не меняю никакие настройки однако прямо сейчас передо мной лежит устройство с доступом к шеллу. BASE_STATION переменная 300 лет назад выкорчевана. Может конечно что-то некорректно залилось в гит, но не существенно. Собсно неогда это выяснять. Насколько я понял, вы все-таки глянули и исправили. Спасибо. Ну т.е. вам нужно а сесть перечитать опусы и сделать должен я? Ну тады нуно было годом раньше очнуться. Мне было бы достаточно ответа: "это никому ненужная фигня, забей" или "да, действительно, patches welcome". # cat kernel/Makefile | grep toolc и где простите? ~/wive-ng/wive-ng $ git show origin:kernel/Makefile | egrep '(WIVE|CROSS)' WIVEROOT = /opt/Wive CROSSPATH = /usr/local/bin/ CROSS_COMPILE = mips-linux- AS = $(CROSSPATH)$(CROSS_COMPILE)as Тут да, но о очевидности однако никто не говорил как и о необходимости пересборки тулчейна. А тулчейн надо пересобирать, если есть желание разместить его по другим путям, а не в /opt/Wive/toolchain или если система 64-битная, или если GLIBC старее 2.7 и т.д. К тому же судя по конфигу пересборка тулчейна интегрирована в процесс, по крайней мере такое впечатление создается и думаешь, что это прозрачно и автоматически. Каждый делает так как угодно ему. FOSS однако. Мне удобно так, если вам так неудобно - переделайте. Естественно. Просто зная вашу нелюбовь к костылям было странно увидеть скрипт для сборки, когда это задача make ;) Чего чего? Вы бы со штатной б разобрались бы со структурой хоть. А то понастроили умозаключений полезли что-то менять, а я вот такой вот дятел не додумался до этого =))))) Да я вроде бы основные идеи понял и скрипты загрузочные читать умею, ага. И мне как-то так кажется, что ramdisk есть ramdisk, если он больше, значит свободной ОЗУ на все остальное меньше. И во время работы все модифицируемые части именно в ramdisk находятся, а только при сохранении создается tar.gz с содержимым и записывается на отдельный mtd раздел. Пробовал ведь, не срабатывает, виснет. JTAG под рукой дома нет, извиняйте. Я же хотел самую клевую прогрессивную прошивку, которая по уму сделана и т.д. Тем более она явно способна работать на этом кастрате не хуже wive. arg s/gЭто еще в нужный момент надо успеть команду дать, после поднятия eth0 и до подключения eth1 в bridge. Не практично, особенно без последовательной консоли.
  3. А отключить после загрузки eth1 принудительно не пробовали?Если использовать тот образ, что в бинарнике с SF.net, то там нет shell на последовательной консоли вообще, а успеть отключить eth1 в тот малый период после старта eth0 по ssh мне не представляется возможным. А в той сборке (все параметры по умолчанию, только в config DEBUG=YES и BASE_STATION=YES, что сейчас я попробовал, наверное, можно успеть, если прямо в терминалку команды правильные вставить, вот только не особо изящный это метод и требует последовательной консоли и пересборки все равно. После bridge start eth1 почти всегда виснет совершенно намертво, ни консоль, ни ssh не работают. Я, конечно, понимаю, что это убогость d-link'а и т.д., но ведь у вас есть хитрый workaround для этого, либо он должен срабатывать, либо вообще по умолчанию eth1 отключить, а кому надо -- включит.
  4. Я смотрю, вы суровый разработчик, похоже, что образы под root'ом собираете :) Вот маленький патч: http://paste.debian.net/59749/. Что касается зависания -- когда виснет, всегда виснет на этапе bridge start eth1. Иногда везет (или, может быть, влияет то, что я держу Enter, чтобы видеть, когда shell на ttyS0 перестанет отвечать), то пишет ``ip: ioctl 0x8914 failed: Cannot allocate memory'' и идет дальше.
  5. Я уже вообще забил на 8186. Не отвечают ни требованиям сегодняшнего для. Работаем над Ralink RT305*. В курсе. А зачем? Почему не отключить всё лишнее в процессе настройки? Чем вам мешает это лишнее банально лежащие на флэше. Только тем, что я не смог настраивать готовый образ после запуска. Вывод консоли с момента включения до перезагрузки в студию.Угу. Только мне кажется, что без /etc/debug информации маловато... http://paste.debian.net/59725/. Timestamps как в minicom сделать я не знаю, по ощущениям до перезагрузки пара минут, могу точнее померить, если надо. Потому что не ориентируюсь на кастрированные 8мб девайсы с одним eth. И что? Казалось бы, логично все отключить, чтобы тот, кому что-то конкретное нужно и включал это, т.к. начинал настройку с заведомо минимальной системы. В общем, дело вкуса, конечно, если настройки по умолчанию не мешают полной загрузки устройства. Чего чего? Вы пробовали лить бинарь который я собирал? Лог после заливки бинарника из wive-ng-0.3.17.tar.7z с SF выше. В исходниках BASE_STATION нигде не устанавливается, а без него shell на последовательной консоли отключен, судя по mkimg и по результату, который я видел после прошивки самособранного образа. Всё проще, вы слишком заморачиваетесь на проблемах которых там нет. Нито не мешал вам просто добавить путь к тулчейну в PATH. Скрипт лежит для основной массы с уровнем сиди я сам открою чтобы 150 раз не объяснять что делать. Путь к дистру задан ровно в одном файле остальное генериться на лету. В любом случае все ваши пожелания советую оформлять дифом а не заставлять читать меня и других километровые опусы. Согласен, что git format-patch для точной передачи идеи гораздо лучше, но и подготовка патча требует больше времени. И если вам сама идея не нравится, то получается, что он того не стоит. Путь к toolchain намертво задан в kernel/Makefile, кстати. И в toolchain/nonmips-tcb/Makefile. Т.е. менять нужно как минимум в нескольких местах, если хочется, что не вполне очевидно. Не нужно вообще запускать make есть скрипк compile доверьте ему процесс сборки. Да, прочитал его до конца, понял. Я-то по наивности думал, что для полной и корректной сборки дистрибутива как раз make с его возможностями по отслеживанию зависимостей использовался. Простите кого предупреждал? =) Пользователя? Для пользователей бинари есть, остальные в состоянии читать что пишут и думать головой а не уменьшать размер рамдиска учитывая что это бессмысленно. Ну вот я ведь головой думал так: у устройства и так мало памяти. Ramdisk забит менее, чем наполовину. В 0.2.x его размер был меньше. Почему бы его и не уменьшить, чтобы иметь лишних 512kiB. А то, что у gz может не получиться записать настройки из-за нехватки места, не сразу в голову приходит, когда пишешь "fs store" и он отвечает, что все ok. Да, выдает gzip ошибку, но не такую уж и очевидную. А ramdisk может по разным причинам забиться -- может пользователь syslog криво настроил или еще что-нибудь такое. И вот он видит ошибку, правит конфиг, fs store, он ему говорит, что все ок, после ребута дефолтные настройки. Круто.
  6. Привет, Евгений, для начала хочу вас поблагодарить за отличную прошивку, грамотный подход и адекватное отношение к GPL. Спасибо большое! По сути дела: так уж получилось, что у нас в лаборатории есть аж 3 "***линка" G700AP и для повышения надежности хотелось бы использовать вменяемую прошивку (по сути нам достаточно просто bridge между wlan и lan). Я знаю, что вы уже не поддерживаете убогие 8-мегабайтные устройства, но решил все же попробовать самостоятельно скомпилировать, отключив лишнее (fyi при прошивке вашего образа 0.3.17 рутер показывал активацию проводных интерфейсов и потом через пару минут перезагружался, видимо по watchdog, без oom killer или kernel panic, просто вдруг перезагружался). Кстати, я не очень понимаю, почему вы по умолчанию не отключаете в прошивке вообще все, кроме eth0 и inetd/dropbear, т.к. все равно же нужно подсоединяться и полностью все отстраивать под свои задачи, но при этом консоль на последовательном порту по умолчанию отключена (и, кстати, то, что mkimg перезаписывает изменения в etc/inittab, было для меня сюрпризом). Комментарии по сборке: Для сборки toolchain я применил gcc 4.3.4, единственная тонкость -- перед make нужно сделать export CFLAGS=-D_FORTIFY_SOURCE=0. Скрипт make_links.sh мне показался сомнительным (у меня в local другие программы тоже установлены, поэтому bin и прочие радости уже присутствуют) и вообще ненужным -- я добавил /opt/Wive/toolchain/bin в PATH перед сборкой. Это оказалось необходимо, т.к. не во всех местах корректно учитывается CROSS_COMPILE, где-то подразумевается, что toolchain доступен в PATH, а в Makefile ядра путь к toolchain вообще hardcoded (знаю, что для 2.6.x достаточно запускать make CROSS_COMPILE=/path/to/chain/prefix-, как это корректно делается в 2.4 -- не интересовался, может это и не важно; как вариант -- добавить include ../.config и заменить = на ?=). Вообще было бы неплохо, чтобы был сразу очевиден метод собрать и установить весь toolchain и прошивку, не имея прав root, это и удобно и безопасно (и порой необходимо, если кто-нибудь захочет собирать это на чужой машине). Даже если для rtl8186 ничего делать уже не имеет смысла, возможно, вы учтете это пожелание для других ваших разработок. Еще непонятный момент: мне показалось, что сборка ramdisk происходит на последнем этапе, уже после линковки ядра, т.о. получается, что после любых изменений файловой системы нужно запускать make два раза подряд. Комментарии по устройству: Насколько я могу понять, работает нормально после отключения ненужных компонентов. Размер ramdisk сделал 512k, но это оказалось совсем впритык -- /tmp/tgzfs не умещался, пока я не удалил пару ненужных конфигов. Возможно, стоит немного подправить скрипт, чтобы он предупреждал пользователя, если не удается его создать, а то получается, что он полуготовый архив записывает, потом, естественно, при перезагрузке возвращается к значениям по умолчанию. Thanks again for all your efforts, Happy hacking!