2018-02-26 0:06 GMT+03:00 Alexander Graf :

...

Am 25.02.2018 um 16:37 schrieb Matwey V. Kornilov :

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.

I guess there is an xml tag we can provide to make /boot ext4 again?

Alex

...

...

And then dtb files cannot be read from /boot partition.

Even without dtb, EFI application cannot be read correctly here:

reading efi/boot/bootaa64.efi MMC: block number 0x100008005 exceeds max(0x1dacc00) MMC: block number 0x100008005 exceeds max(0x1dacc00) Invalid FAT entry 6144 bytes read in 11 ms (544.9 KiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC ## Starting EFI application at 02000000 ... Unknown Relocation off ffe type f ## Application terminated, r = 9223372036854775806 EFI LOAD FAILED: continuing...

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

-- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

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 :

...

...

Am 25.02.2018 um 16:37 schrieb Matwey V. Kornilov :

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).

...

...

I guess there is an xml tag we can provide to make /boot ext4 again?

I've changed the xml to explicitly have a /boot partition in ext4.

Thanks.

Alex

-- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

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 :

...

...

Am 25.02.2018 um 16:37 schrieb Matwey V. Kornilov :

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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 27.02.18 11:18, Michal Suchánek wrote:

On Mon, 26 Feb 2018 23:29:49 +0300 "Matwey V. Kornilov" 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 : > > >> Am 25.02.2018 um 16:37 schrieb Matwey V. Kornilov >> : >> >> 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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org