wip: buildroot 2024.11.1

[gjrtimmer]

WORK IN PROGRESS

This PR is in draft, this PR requires #230

Linked Issues

• feat: upgrade buildroot #235
• feat: devcontainer development #230 (Requirement)

I have started a PR for updating buildroot to 2024.11.1.

• fix: cargo patch
• fix: rust-bin patch (removed: not necessary)
• fix: PVM patch
• fix: i2c patch
• Fix realtek-switch

NOTE: i2c
To make development and repatching for future versions more easy, I have separated the i2c patches.

Current Status

I am currently trying to figure out what to do with the Realtek patch; the source is entirely different, so I am unsure what to do.

@CFSworks Could you look at the Realtek patch, please for buildroot 2024.11.1.

[svenrademakers]

@gjrtimmer its strange the source is completely different. Can you confirm you did the following steps

• checkout tag v6.8.12 in the linux stable repo
• apply the turing pi patches on top of v6.8.12
• git rebase --onto v6.11.11 v6.8.12

[gjrtimmer]

@gjrtimmer its strange the source is completely different. Can you confirm you did the following steps

• checkout tag v6.8.12 in the linux stable repo
• apply the turing pi patches on top of v6.8.12
• git rebase --onto v6.11.11 v6.8.12

@svenrademakers That is not what I did, I upgraded the buildroot to 2024.11.1 in the new configure.sh script, the previous setup_build.sh script, and then ran build. That when I ran into issues. I was unaware of the git rebase. Never done this before.

So run the patches on the linux kernel 6.8.12, and then rebase to 6.11.11 However, a lot of the realtek code was rewritten.
Buildroot 2024.11.1 checkouts kernel 6.11.11 and this one has different realtek code that does not match, regarding the other patches, it was mainly offsets manually reapply and recreate the patch.

Will try and figure out what it is what you exactly mean by the rebase, I think I understand what the goal is.

[svenrademakers]

i just cherry-picked the realtek-patches on top of v6.11.11 to see the diff. and it needs to have a bit of porting to make it build on v6.11.11. Until so far i did not touched much this driver, so i cannot really assist you here. Even though this task would be a good opportunity to do so. but feel free to give it a go.

To make sure the patches apply cleanly, its good practice to re-create them using the correct source-tree, and then export them again into this repository so they are picked up nicely by buildroot without any issues. without going into much detail, my workflow is usually as i described earlier. clone stable linux git repo, checkout old version, git am patches directory onto it. rebase to new version, resolve merge conflicts, export mailboxes again with git format-patch

[gjrtimmer]

@CFSworks Are you able to provide assistance?

[gjrtimmer]

merge conflicts, export mailboxes again with git format-patch

Are you talking about the checkout of linux kernel from kernel.org ?

[gjrtimmer]

So I have the following so far.

Clone kernel.org
git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
cd linux

git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
git checkout
cd linux
git checkout v6.8.12
git status
cd ..
git apply --directory=linux --verbose tp2bmc/patches/linux/0001-regulator-fixed-perserve-boot-state.patch
Checking patch linux/drivers/gpio/gpio-latch.c...
Checking patch linux/drivers/regulator/fixed.c...
Checking patch linux/include/linux/regulator/fixed.h...
Applied patch linux/drivers/gpio/gpio-latch.c cleanly.
Applied patch linux/drivers/regulator/fixed.c cleanly.
Applied patch linux/include/linux/regulator/fixed.h cleanly.

git status
HEAD detached at v6.8.12
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   drivers/gpio/gpio-latch.c
        modified:   drivers/regulator/fixed.c
        modified:   include/linux/regulator/fixed.h

no changes added to commit (use "git add" and/or "git commit -a")

Then I have to commit these changes; otherwise, rebase is impossible unless I'm doing something wrong.

git commit -m "patch(tpi): perserve boot"
```

But then then when I try to rebase onto the v6.11.11 I am being hit with a lot of merge conflicts on files that to my knowledge have nothing to do with this patch.

```shell
git rebase --onto v6.11.11 v6.8.11
```

Example:
```shell
dropping 8d00da6502a07f9f8d7e6d4ae29d4338db056118 sunrpc: use the struct net as the svc proc private -- patch contents already upstream
dropping e2f1bbf96853a928d2f025bef94e3fa33eabbcac x86/tsc: Trust initial offset in architectural TSC-adjust MSRs -- patch contents already upstream
dropping 526de9d9e11f6c8e1947d2ded29dd9ae15abf03a selftests/ftrace: Fix BTFARG testcase to check fprobe is enabled correctly -- patch contents already upstream
dropping 66df065b3106964e667b37bf8f7e55ec69d0c1f6 ftrace: Fix possible use-after-free issue in ftrace_location() -- patch contents already upstream
dropping e003c485ac82a9f8de4204912ed059ac6dd4257c arm64/fpsimd: Avoid erroneous elide of user state reload -- patch contents already upstream
Auto-merging drivers/tty/n_gsm.c
CONFLICT (content): Merge conflict in drivers/tty/n_gsm.c
error: could not apply f126ce7305fe... tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply f126ce7305fe... tty: n_gsm: fix possible out-of-bounds in gsm0_receive()

@svenrademakers So I think I might be doing something wrong. Can you provide some directions?

[svenrademakers]

@gjrtimmer you are on the right path:

• git apply is not meant for mailboxes. Could you try to use git am <path-to-bmc-repo>/tp2bmc/patches/linux/*.
  If you use this i think you will have a preserved commit history which should make resolving conflicts easier.
• you are right that you need to commit the patches, i dont think you can rebase with working changes?

[gjrtimmer]

Yeah, you cannot rebase with working changes