Столкнулся с ситуацией, что если обновлять загрузчик u-boot утилитой kobs-ng, работая при этом из-под рутовой файловой системы в NAND, то разрушается эта файловая система.
Я так понимаю, что причина в том, что нельзя шить в NAND если работаешь из NAND.
В частности после запуска
начинают сыпаться ошибки
и файловая система после перезагрузки уже не работает, имеем kernel panic.
Вопрос:
можно ли в принципе осуществить обновление u-boot (а потом и ядра), если загрузился с рутовой в NAND ?
Что я пробовал:
попробовал менять корневой каталог командой chroot на SD карточку, где лежит дубликат файловой системы.
Однако при этом не пойму как отмонтировать NAND, на мои попытки выдается ошибка device busy.
Зачем мне это нужно:
Нужно обновлять прошивку девайса без вскрытия корпуса, т.е. без всяких механических манипуляций с подключением Ethernet кабеля или вставлением другой SD карты.
Все что у меня есть в доступе - это USB коннектор, через который я могу заливать на устройство файлы посредством USB Gadget (девайс определяется как USB drive и доступен для записи).
Покажите полный лог загрузки начиная от включения питания до приглашения входа вашей работающей системы до прошивки u-boot, лучше наверно на внешний ресурс типа http://pastebin.com
Там же по ссылке предложено решение (kexec), которое сейчас буду пробовать. Но очень уж непростой алгоритм выходит (запускать временное ядро с временной рутовой системой, чтобы перешить NAND, а затем снова рестартовать уже из NANDа).
Судя по логам - все штатное. Я потом попробую зашить с рутовой в nand но на другой плате - у меня нет oem, есть старая ревизия с ddr2 256MB, но мне не понятен смыл ваших страданий :) Зачем обновлять загрузчик ? Если загрузчик цел - вообще никакого смысла нет, если его нет то кроме как с MFG вы уже не загрузитесь
Этого для MFG достаточно - штатно ему больше ничего не надо - в этом и есть его ценность (жаль под Linux не работает), SD и прочие прибамбасы это уже выдумки Павла :)
Смысл страданий:
Загрузчик цел, но его нужно поменять, т.к. стоит задача выполнить ряд операций как можно раньше с момента включения устройства. А это "раньше" и есть загрузчик u-boot, т.к. ядро и прикладной софт стартуют слишком поздно (особенно учитывая что заводской u-boot имеет 3 секундную паузу для входа в консоль).
MFG не подходит, т.к. для него нужно размыкать\замыкать перемычку CS, а следовательно вскрывать прибор.
Смысл в том, чтобы обновить прошивку без вскрытия.
Так у вас свой загрузчик или или тот же u-boot но с отключенной паузой ? Если второе:
setenv bootdelay 0
saveenv
только потом вы его его уже не остановите :) штатно не включена опция CONFIG_ZERO_BOOTDELAY_CHECK.
Вот именно поэтому я рекомендую вообще не трогать загрузчик, а то потом некоторые даже без всяких корпусов не могут его восстановить. Кстати я не понял - почему на oem нет перемычек выбора загрузки, на обычных платах раньше они были, потом только площадки хотя бы остались - при их наличии элементарно вывести на корпус кнопку и при необходимости включать режим serial download для принудительной загрузки с USB независимо от CS NAND
2. Изменение паузы в u-boot это только пол дела.
Еще выставляем свои GPIO (нужно подать питание на подсветку дисплея) + в будущем планируется splash screen прямо из u-boot.
3. Перемычка NAND CS на плате OEM есть.
Однако в нашем проекте выводить соотв. кнопку/переключатель на корпус нельзя, т.к. прибор в общем случае не для продвинутого пользователя, а для чайника. Нельзя ему лишних кнопочек/переключателей давать.
Смотрю на все это и что то слабо понимаю ...
У вас со штатными прошивками, при обновлении u-boot (через kobs-ng) корневая ФС рушится?
Само собой просится эксперимент - изменить партиции - увеличить раздел для загрузчика (что он не затирал ФС).