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