Re: [opensuse-arm] Re: JeOS-efi.aarch64-2018.02.22: Failed to mount ext2 filesystem

2018-02-26 Thread Matwey V. Kornilov 
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+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Re: JeOS-efi.aarch64-2018.02.22: Failed to mount ext2 filesystem

2018-02-26 Thread 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.


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

Re: [opensuse-arm] Re: JeOS-efi.aarch64-2018.02.22: Failed to mount ext2 filesystem

2018-02-26 Thread Matwey V. Kornilov 
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+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] Re: JeOS-efi.aarch64-2018.02.22: Failed to mount ext2 filesystem

2018-02-26 Thread 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.

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


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