On 27.02.18 11:18, Michal Suchánek wrote: > On Mon, 26 Feb 2018 23:29:49 +0300 > "Matwey V. Kornilov" <matwey.korni...@gmail.com> wrote: > >> 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. >> > > I think the goal is to support the features required by u-boot by the > DT included in u-boot and new development happens in Linux with > occasional sync. As in it is not expected that the tree provided by > u-boot will work with Linux as well without extra effort. > > So there are a few options here: > > - update devicetrees for boards we build for in u-boot. This might not > work flawlessly due to driver differences between u-boot and Linux. > This should not happen but some bugs might creep in occasionally
This should simply happen in upstream U-Boot if we identify such a case ;). We're not yet another Yocto distro that patches every upstream package to death. > - provide separate package of devicetrees which is completely separate > from kernel and u-boot and installs devicetrees somewhere where the > u-boot scripts find them We do generate dtb packages from the Linux source tree today. I'm not sure what source you would take them from? > - update, build and use the devicetrees from Linux - some dtb packages > are built but the devicetrees are not updated on the basis that the > in-kernel devicetrees are not used for booting ????? This is the case that's happening for Matwey today already. He's relying on the device trees that pop out from the kernel build. Just today, I learned that U-Boot grew btrfs support though, so maybe we could just completely avoid the boot partition altogether if we enable btrfs support in U-Boot. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
