On Mon, 26 Feb 2018 23:29:49 +0300 "Matwey V. Kornilov" <matwey.kornilov@gmail.com> wrote:
2018-02-26 23:18 GMT+03:00 Alexander Graf <agraf@suse.de>:
On 26.02.18 20:36, Matwey V. Kornilov wrote:
2018-02-26 22:07 GMT+03:00 Alexander Graf <agraf@suse.de>:
On 26.02.18 08:19, Matwey V. Kornilov wrote:
2018-02-26 0:06 GMT+03:00 Alexander Graf <agraf@suse.de>:
> Am 25.02.2018 um 16:37 schrieb Matwey V. Kornilov > <matwey.kornilov@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 - 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: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org