Bug 1185656 - u-boot is unable to load DTB automatically from BTRFS partition
u-boot is unable to load DTB automatically from BTRFS partition
Status: RESOLVED UPSTREAM
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Bootloader
Current
All openSUSE Tumbleweed
: P5 - None : Normal (vote)
: ---
Assigned To: Matthias Brugger
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2021-05-05 13:37 UTC by Guillaume GARDET
Modified: 2021-10-28 20:35 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Guillaume GARDET 2021-05-05 13:37:52 UTC
u-boot is unable to load DTB automatically from BTRFS partition.

I suspect the @ and .snapshots paths, specific to btrfs, to break it. We should have the default path to use latest version of the file.
Comment 1 Matthias Brugger 2021-05-11 16:14:49 UTC
Do you know what has changed there over time? This used to work, right?
Comment 2 Guillaume GARDET 2021-05-11 16:25:24 UTC
(In reply to Matthias Brugger from comment #1)
> Do you know what has changed there over time? This used to work, right?

I am not sure it ever worked in u-boot.
Comment 3 Matwey Kornilov 2021-07-13 18:30:10 UTC
(In reply to Guillaume GARDET from comment #2)
> (In reply to Matthias Brugger from comment #1)
> > Do you know what has changed there over time? This used to work, right?
> 
> I am not sure it ever worked in u-boot.

I am afraid it did work previously. As far as I remember rock64 dtb from u-boot source tree considerable differed from the linux kernel one. And it was not possible to boot linux kernel with u-boot dtb. So, reading dtb from the filesystem was important. And I do remember that rock64 worked fine with btrfs filesystem :-)
Comment 4 Matwey Kornilov 2021-07-19 09:28:36 UTC
I double checked. We used to have separate /boot ext4fs partition previously.
Comment 5 Matwey Kornilov 2021-08-02 15:45:49 UTC
Upstream discussion:
https://lists.denx.de/pipermail/u-boot/2021-August/456764.html
Comment 6 Matthias Brugger 2021-08-02 17:18:58 UTC
WenRuo can you have a look on the patch provided upstream by Matwey?
Comment 7 Wenruo Qu 2021-08-03 00:37:17 UTC
Already reviewed.

It's indeed the default subvolume causing the problem.
The patch should solve it properly.
Comment 8 Guillaume GARDET 2021-08-03 08:38:02 UTC
I added the patch on top of our 2021.07 branch and submitted it to Factory https://build.opensuse.org/request/show/909899
Comment 9 Guillaume GARDET 2021-09-01 09:43:15 UTC
It seems that upstream did not merge it yet. Any issue preventing the merge?
It would be great to have it upstream for 2021.10 (we are at -rc3 already).
Comment 10 Wenruo Qu 2021-09-01 10:19:43 UTC
(In reply to Guillaume GARDET from comment #9)
> It seems that upstream did not merge it yet. Any issue preventing the merge?
> It would be great to have it upstream for 2021.10 (we are at -rc3 already).

I guess it's just usual Uboot merge cycle thing.

Or you can try to ping the patch, but I doubt if it would speed up the progress.
Comment 11 Matthias Brugger 2021-09-01 11:33:30 UTC
(In reply to Wenruo Qu from comment #10)
> (In reply to Guillaume GARDET from comment #9)
> > It seems that upstream did not merge it yet. Any issue preventing the merge?
> > It would be great to have it upstream for 2021.10 (we are at -rc3 already).
> 
> I guess it's just usual Uboot merge cycle thing.
> 
> Or you can try to ping the patch, but I doubt if it would speed up the
> progress.

I just pinged Tim Rini on the mailinglist and asked him, if there is any problem with merging the patch. I suppose it's an oversight from him, but we'll see.
Comment 12 Matthias Brugger 2021-09-02 09:50:03 UTC
Now applied upstream. Thanks for the help Qu and Matwey
Comment 13 Guillaume GARDET 2021-09-02 12:29:55 UTC
For the record, upstream commit is https://source.denx.de/u-boot/u-boot/-/commit/94509b79b13e69c209199af0757afbde8d2ebd6d