NAND device: Manufacturer ID: 0x98, Chip ID: 0xf1 (Toshiba NAND 128MiB 3,3V 8-bit), 128MiB, page size: 2048, OOB size: 64
В общем, собрал образ с разлоченым mtd0 и снес его нах. И, о чудо, оно загрузилось само (openwrt), без сторонней помощи...
Что бы там не лежало на том mtd0 (кусок или целая прошивка, такая же как в spi flash обернутая еще какой то сранью), по идее, оно предназначено для обычной загрузки и должно иметь последнюю версию (в моем случае когда снимал копию там похоже была версия 3.19. которую залил предыдущий хозяин чем собственно и окирпичил его).
На данный момент имею свежесобранный openwrt barrier_braker залитый соответственно по mtd1 и mtd2 и кое как сам стартующий при включении питания (однократному бипу предшествует затяжное чирикание в 1-1,5секунды, плюс на время загрузки нельзя вставлять кабель в wan порт, иначе загрузка подвисает - возможно он пытается загрузиться с внешнего ресурса по дхцп, собственно в ван порту он присутствовал от другого роутера, только продолжения тфтп небыло, а без wan провода перебирает следующий доступный, но все же аварийный способ - который находит ядро на mtd1).
Собственно теперь перехожу к более нереальной задаче в тыканиях в потемках - раскурить секцию Soft (и как Tolyan справедливо замечает - это онанизм в чистом виде). Но, все же, попытка не пытка и может кому то сократит время понимания процессов в этих чудо поделиях и предложит вариант по спасению от последствий обновления и "улучшений" в паршивках от микротиков.
Tolyan, выражаю еще раз благодарность в наталкивании на новую соломинку в исследованиях:
Собственно, меня глодала мысль как работает rbcfg, и пришел к выводу (после сноса mtd0) что СТАРАЯ версия тулзы по идее должна была работать через определившийся spi 0.0 m25p80 девайс в процессе загрузки посредством mtd уровня, но увы - в новых версиях openwrt они уже работают какось иначе, похоже напряму по gpio без всяких формальностей. Причиной сему думаю может быть постоянная смена адресов расположения паттернов Hard, Soft, Bios.
Почему я так думаю - потому что на эту мысль натолкнуло то, что wifi модуль на последней openwrt barrier_braker (без работающего светодиода wlan) поднялся и заработал, без проблем, как пишет книжка. Это говорит о том, что настройки радио были считаны (mtd0 был пуст, а spi 0.0 m25p80 не определен в dmesg)! Но как?! И тут начинается следующий этап самоудовлетворения - копание в исходниках openwrt barrier_braker. Если коротко - то там есть куски кода в разных файлах, которые работают (хз пойми каким ёбразом) через rbcfg.
Т.е., говоря иначе, настройки радио этот гад прочел, а настройки загрузки - нет. А возможность в работе rbcfg утилиты такая есть. И она знает где что расположено в этих конфигах и умеет (может быть, а может -нет) правильно запаковать с crc и писать на spi в свое место. Хотя есть сомнения что она это делала/ет корректно, ибо на форуме микротыка один чел который повредил последовательность загрузки этой тулзой и получил практически мой вариант работы до сноса mtd0 (загрузки) - загрузка с кнопки ресет.
Собственно есть мой Soft кусок http://res.cloudinary.com/metsys/ima...rb951_soft.png и есть исходник https://dev.openwrt.org/browser/trun...cfg/src/main.c с помощью которого мне кажется можно что то восстановить.
Однако на spi есть и другие фрагменты назначение которых непонятно, может это ключ, а может хз что еще http://res.cloudinary.com/metsys/ima...000_0xF040.png
После таких плясок с бубном возникает желание вообще снести нахер все, что связано с микротиковским софтом. Как вариант - попробовать залить uboot под этот проц, будет больше пользы людям, чем постоянно сталкиваться с дебилизмом и изменениями в routerbootах от микротика.
ps
надежд на "серебряную пулю" все меньше и меньше, но может все еще удасться как то заставить нетинсталл увидеть свое поделие - думаю повычищать из spi всё, что не относится к минимально необходимому для загрузки (удалить неведомые блоки, упоминания про последнюю версию routerboot в mtd0) ...
В общем, собрал образ с разлоченым mtd0 и снес его нах. И, о чудо, оно загрузилось само (openwrt), без сторонней помощи...
Что бы там не лежало на том mtd0 (кусок или целая прошивка, такая же как в spi flash обернутая еще какой то сранью), по идее, оно предназначено для обычной загрузки и должно иметь последнюю версию (в моем случае когда снимал копию там похоже была версия 3.19. которую залил предыдущий хозяин чем собственно и окирпичил его).
На данный момент имею свежесобранный openwrt barrier_braker залитый соответственно по mtd1 и mtd2 и кое как сам стартующий при включении питания (однократному бипу предшествует затяжное чирикание в 1-1,5секунды, плюс на время загрузки нельзя вставлять кабель в wan порт, иначе загрузка подвисает - возможно он пытается загрузиться с внешнего ресурса по дхцп, собственно в ван порту он присутствовал от другого роутера, только продолжения тфтп небыло, а без wan провода перебирает следующий доступный, но все же аварийный способ - который находит ядро на mtd1).
Собственно теперь перехожу к более нереальной задаче в тыканиях в потемках - раскурить секцию Soft (и как Tolyan справедливо замечает - это онанизм в чистом виде). Но, все же, попытка не пытка и может кому то сократит время понимания процессов в этих чудо поделиях и предложит вариант по спасению от последствий обновления и "улучшений" в паршивках от микротиков.
Tolyan, выражаю еще раз благодарность в наталкивании на новую соломинку в исследованиях:
Собственно, меня глодала мысль как работает rbcfg, и пришел к выводу (после сноса mtd0) что СТАРАЯ версия тулзы по идее должна была работать через определившийся spi 0.0 m25p80 девайс в процессе загрузки посредством mtd уровня, но увы - в новых версиях openwrt они уже работают какось иначе, похоже напряму по gpio без всяких формальностей. Причиной сему думаю может быть постоянная смена адресов расположения паттернов Hard, Soft, Bios.
Почему я так думаю - потому что на эту мысль натолкнуло то, что wifi модуль на последней openwrt barrier_braker (без работающего светодиода wlan) поднялся и заработал, без проблем, как пишет книжка. Это говорит о том, что настройки радио были считаны (mtd0 был пуст, а spi 0.0 m25p80 не определен в dmesg)! Но как?! И тут начинается следующий этап самоудовлетворения - копание в исходниках openwrt barrier_braker. Если коротко - то там есть куски кода в разных файлах, которые работают (хз пойми каким ёбразом) через rbcfg.
Т.е., говоря иначе, настройки радио этот гад прочел, а настройки загрузки - нет. А возможность в работе rbcfg утилиты такая есть. И она знает где что расположено в этих конфигах и умеет (может быть, а может -нет) правильно запаковать с crc и писать на spi в свое место. Хотя есть сомнения что она это делала/ет корректно, ибо на форуме микротыка один чел который повредил последовательность загрузки этой тулзой и получил практически мой вариант работы до сноса mtd0 (загрузки) - загрузка с кнопки ресет.
Собственно есть мой Soft кусок http://res.cloudinary.com/metsys/ima...rb951_soft.png и есть исходник https://dev.openwrt.org/browser/trun...cfg/src/main.c с помощью которого мне кажется можно что то восстановить.
Однако на spi есть и другие фрагменты назначение которых непонятно, может это ключ, а может хз что еще http://res.cloudinary.com/metsys/ima...000_0xF040.png
После таких плясок с бубном возникает желание вообще снести нахер все, что связано с микротиковским софтом. Как вариант - попробовать залить uboot под этот проц, будет больше пользы людям, чем постоянно сталкиваться с дебилизмом и изменениями в routerbootах от микротика.
ps
надежд на "серебряную пулю" все меньше и меньше, но может все еще удасться как то заставить нетинсталл увидеть свое поделие - думаю повычищать из spi всё, что не относится к минимально необходимому для загрузки (удалить неведомые блоки, упоминания про последнюю версию routerboot в mtd0) ...
Комментарий