On Mon, 26 Feb 2018 23:29:49 +0300 "Matwey V. Kornilov" <[email protected]> wrote:
> 2018-02-26 23:18 GMT+03:00 Alexander Graf <[email protected]>: > > > > > > On 26.02.18 20:36, Matwey V. Kornilov wrote: > >> 2018-02-26 22:07 GMT+03:00 Alexander Graf <[email protected]>: > >>> > >>> > >>> On 26.02.18 08:19, Matwey V. Kornilov wrote: > >>>> 2018-02-26 0:06 GMT+03:00 Alexander Graf <[email protected]>: > >>>>> > >>>>> > >>>>>> Am 25.02.2018 um 16:37 schrieb Matwey V. Kornilov > >>>>>> <[email protected]>: > >>>>>> > >>>>>> 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 - 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 - 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 ????? Thanks Michal -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
