2018-02-26 23:18 GMT+03:00 Alexander Graf <ag...@suse.de>: > > > On 26.02.18 20:36, Matwey V. Kornilov wrote: >> 2018-02-26 22:07 GMT+03:00 Alexander Graf <ag...@suse.de>: >>> >>> >>> On 26.02.18 08:19, Matwey V. Kornilov wrote: >>>> 2018-02-26 0:06 GMT+03:00 Alexander Graf <ag...@suse.de>: >>>>> >>>>> >>>>>> Am 25.02.2018 um 16:37 schrieb Matwey V. Kornilov >>>>>> <matwey.korni...@gmail.com>: >>>>>> >>>>>> 25.02.2018 18:22, Matwey V. Kornilov пишет: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I am faced the issue that recent JeOS builds cannot be read by u-boot: >>>>>>> >>>>>>> ls mmc 1:2 / >>>>>>> Failed to mount ext2 filesystem... >>>>>>> ** Unrecognized filesystem type ** >>>>>> >>>>>> Hm, Now I see. Why do you use btrfs for having separate /boot partition? >>>>>> Is there any reason for it? >>>>> >>>>> I assume that change came with the seitch to python-kiwi. I assume the >>>>> main rationale would be snapshotting of /boot, so you can load old >>>>> kernels. >>>>> >>>> >>>> /lib/modules are on the separate partition, so it won't work anyway. >>>> We could have united / and put dtb files onto separate EFI partition >>>> for snapshotting kernels. >>> >>> Nah, if you go that far, better ensure the built-in device tree from >>> U-Boot contains a device tree that just covers everything you need. That >>> way you don't need to load any dtb files. The dtb loading from /boot is >>> really mostly there for cases where firmware is "broken" and does not >>> deliver good, upstream compatible device trees. >>> >> >> Well, it would be full of pain way, especially in cases when one >> bootloader fits multiple dtb-s (i.e. am335x). > > It depends. Currently, U-Boot needs to detect the board and find a > different dtb. Instead, it could easily just pick a different built-in dtb. > > Depending on the board you're on, it may even be the easiest way > forward. As soon as U-Boot 2018.03 is in Factory, I'll move the > Raspberry Pi to a model where the RPi firmware provided devices tree > gets propagated all the way to U-Boot as well as Linux. And that makes > things easier at the end of the day, because we don't need to > synchronize 3 different DTs throughout the boot process. >
At least, neither rk3328 nor marvel 3700 espressobin not able to boot the kernel using bundled u-boot dtb. I think this should be primarily solved upstream, if they would manage to merge dts trees between different projects. > > Alex -- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
