Alexander Galanin <a...@galanin.nnov.ru> wrote: > 26.04.2019 22:48, Andrey Jr. Melnikov пишет: > >> Я попробовал перепаковать initrd.gz с помощью xz -9. Было 8111803 байт, > >> стало 5919008, но это больше 5 Мб. Всё равно б не помогло. > > > > Эм. У тебя там весь SPI-флеш чтоль 8 мегабайт? Новый напаять не вариант?
> Знаешь ведь, наверно, что разбивка mtd в u-boot задаётся через > редактирование исходников. А перекомпилировать и перепрошивать его я не u-boot написан таким образом, что знает только про несколько критических вещей - размер самого себя в блоках от начала флешки, размер своего енвайромента (тут возможен вендорский хак со своим art/firmware/bloatware кусоком) и после всего этого начинается kernel. Полная длинна флеша u-boot не интересует никак. Ему нужно знать откуда считать uImage заголовк, загрузить необходимое количесто байт за ним (kernel), проверить crc, распаковать и передать управление. В старых (так любимых всякими вендорами похачить код и зажать) версиях - вся эта магия была на дефайнах с математикой через размер стираемой страницы, в новых - к математике вокруг CONFIG_SYS_FLASH_BASE + CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE https://elixir.bootlin.com/u-boot/v2019.04/source/include/environment.h#L24 добавились пляски вокруг dts (но там обычно только описатели оборудования) и скриптов вида: nand read 0x70000000 0x200000 0x300000; bootm 0x70000000 (где 0x70000000 куда грузим имадж, 0x200000 оффсет от начала флешки кратный размеру страницы, 0x300000 длинна загружаемого куска кратная размеру страницы.); т.е. если раньше была некая уверенность, что за u-boot-env можно найти uImage с ядром и прочее - то теперь этот uImage может находиться где угодно и как угодно.
