sunxi/sunxi64: bump edge to 6.12 via copy
#7577
Conversation
The-going
requested review from
AGM1968,
JohnTheCoolingFan,
NicoD-SBC,
PanderMusubi,
Tonymac32,
janprunk,
krachlatte,
pyavitz,
schwar3kat,
sgjava,
teknoid and
igorpecovnik
as code owners
github-actions
bot
added
size/large
|
This PR is missing my recent PR: #7568 |
The-going
force-pushed
the
main-sunxi-6.12
branch
from
088d319 to
99c3555
Compare
|
Fails to build kernel debs |
I don't have anything doing at all. I'm deleting the cache for kernel packages. |
|
Doesn't happen when I build 6.11.y. |
Patrick, please tell me how I can reproduce it. |
|
I reproduced the build error. If I collect only DTB, then the assembly is successful, but the package packer fails and writes this error: We can see that the assembly of the target files was successful. P.S. Incorrect logic in function @rpardini I can see what we're doing in this function, but I don't really understand why. |
|
The error occurs if a variable is initialized: If you write as: |
Didn't you recently remove the vendor name from the bananapim4zero.conf file along with 2 other confs? I'm still unsure why this is only affecting the 6.12.y builds. |
Perhaps the branch where you built for 6.11 should be rebased as: build for 6.11: Similarly |
When I tested it yesterday I pulled |
|
My error is diff than the one you are showing, I thinks. |
Patrick, please tell me how I can reproduce it. |
All i did was and went through the motions. I mean if it's just me, than I don't know? But I can say for sure it doesn't happen when building 6.6.y and 6.11.y. |
If that's the only goal, then it's probably possible to change it for all architectures. This is a very good feature. |
It depends on the u-boot code, which searches for the target DTB in a path that does not contain a vendor folder. But armbian can take into account different paths and do it in the boot.cmd boot script. |
Interesting, that explains a lot. @paolosabatino does that also apply for rk32? |
|
|
I'm going on New Year's holidays and will be available after January 15th. |
|
@rpardini yes, the issue is present on 32 bit rockchips too, see this comment. As I understand correctly, on 64 bit architectures the device tree binaries are in instead 32 bit architectures device tree binaries are in The "very convoluted" makefile rules are there to remove the vendor from the paths; if I remember correctly, not removing the vendor from the dtbs pathname would cause 32bit architectures to break because the dtbs would be in the 64-bit style paths (eg: As @The-going is saying to accomodate such a change, I guess The very same patch is used in both |
|
Thanks, it's clear now. For now, let's keep this scheme (stripping vendor folder from 32-bit stuff) and I will just adapt For the (somewhat distant) future, adding the proper Thanks all for the inputs here. |
rpardini
force-pushed
the
main-sunxi-6.12
branch
from
6eb5509 to
8173553
Compare
|
|
Well, I cherry picked this PR. It builds fine. I couldn't reproduce the alledged "make clean"
I tried on both x86 and arm64 build hosts. Thus none of this makes any sense to me. Maybe something changed upstream since @The-going found it? I'd simply drop the commit with the |
rpardini
changed the title
edge to 6.12 via copy
|
@amazingfate helped me find the underlying cause. See #7604 (comment) |
First of all, we make changes to the core functions and only then we change the device tree
Here, a folder named patches.addon must exist in order for users to add new patches. These patches will be applied but they are awaiting more careful consideration. Let's just sort the sequence a little bit.
It will be useful for us to receive the trace stack from users.
Add the missing fixes from armbian#7568 and re-extracted the patches.
…ools. In order for the cleanup to be correct for tools, we need to pass the VMLINUX_BTF variable, which contains the real path to the vmlinux file we just compiled. The vmlinux file itself is not involved in cleaning, but the Makefile checks for its presence and cleaning is aborted if it is not found.
rpardini
force-pushed
the
main-sunxi-6.12
branch
from
8173553 to
1c5ad4f
Compare
|
See #7625 indeed for the discussion; simply not-calling make clean in tools results in binaries being shipped in linux-headers, and if cross-compiling, for the wrong architecture. After considering all the factors at play here, I think @The-going 's proposed solution (passing a fake Thank you all so much for the learnings here and sorry for the back and forth's. |
Description
How Has This Been Tested?
A kernel with patches already applied:
main-sunxi-6.12