In revieweing Debian's kernel configuration for sh4, I realised that
the sh7785lcr board file not only has a small kernel partition but has
no initramfs partition.
Some time ago the compressed kernel image for sh7785lcr became larger
than its kernel partition. This was caught by a build-time check. In version 6.3.2-1~exp1 I attempted to fix this by modularising some
drivers, on the assumption that an initramfs would be used (as is
normal for Debian packaged kernels). But it seems like this won't work
- any initramfs would have to be appended to the kernel image, so it
would still be too large for the kernel partition.
**If this kernel flavour is no longer usable and no fix is proposed, I
intend to remove it.**
Before I do that:
- Does anyone still care about this board?
- Does anyone have it working with a recent (6.3 or later) Debian
kernel package, and if so how?
- Does anyone have it working with a recent (6.3 or later) Debian
kernel package, and if so how?
I am currently running a kernel built from git upstream, but I would love
to be able to boot a Debian kernel again. I have no clue how to reduce
the kernel image size at this point though.
I am currently not using an initrd with my custom kernel.
On Sat, 2024-07-20 at 21:48 +0200, John Paul Adrian Glaubitz wrote:
[...]
- Does anyone have it working with a recent (6.3 or later) Debian
kernel package, and if so how?
I am currently running a kernel built from git upstream, but I would love to be able to boot a Debian kernel again. I have no clue how to reduce
the kernel image size at this point though.
I am currently not using an initrd with my custom kernel.
I made some config changes that bring the size back under the limit: <https://salsa.debian.org/kernel-team/linux/-/merge_requests/1133>.
Can you test that this produces a working kernel?
I'll give it a try next week as I'm currently not at home and unable
to access the board for testing. While I can reach the board via SSH,
I don't have any kind of remote management.
Are you able to test now?
Hi Ben,
On Sun, 2024-07-21 at 15:16 +0200, Ben Hutchings wrote:
On Sat, 2024-07-20 at 21:48 +0200, John Paul Adrian Glaubitz wrote:
[...]
- Does anyone have it working with a recent (6.3 or later) Debian
kernel package, and if so how?
I am currently running a kernel built from git upstream, but I would love to be able to boot a Debian kernel again. I have no clue how to reduce the kernel image size at this point though.
I am currently not using an initrd with my custom kernel.
I made some config changes that bring the size back under the limit: <https://salsa.debian.org/kernel-team/linux/-/merge_requests/1133>.
Can you test that this produces a working kernel?
I'll give it a try next week as I'm currently not at home and unable
to access the board for testing. While I can reach the board via SSH,
I don't have any kind of remote management.
On Tue, 2024-09-10 at 21:16 +0200, Ben Hutchings wrote:
I'll give it a try next week as I'm currently not at home and unable
to access the board for testing. While I can reach the board via SSH,
I don't have any kind of remote management.
Are you able to test now?
Yes, I can give it a try tomorrow. Can I just apply the changes from the branch on top of the current kernel package and then just build the package with "dpkg-buildpackage -B" or is there anything else I need to know?
Yes, I can give it a try tomorrow. Can I just apply the changes from the branch on top of the current kernel package and then just build the package with "dpkg-buildpackage -B" or is there anything else I need to know?
A few things (that you may know already):
- You can speed this up by deleting the other sh4 flavour definition in
debian/config/sh4/defines.toml.
- Run "debian/rules debian/control-real" before building (and after
deleting the other flavour).
- If you are cross building, use the "cross" build-profile.
- You can skip building user-space packages by using the
"pkg.linux.notools" build profile. (Without that, cross-build-
dependencies may often be unsatisfiable due to version skew.)
On Tue, 2024-09-10 at 21:43 +0200, Ben Hutchings wrote:
Yes, I can give it a try tomorrow. Can I just apply the changes from the branch on top of the current kernel package and then just build the package
with "dpkg-buildpackage -B" or is there anything else I need to know?
A few things (that you may know already):
- You can speed this up by deleting the other sh4 flavour definition in
debian/config/sh4/defines.toml.
- Run "debian/rules debian/control-real" before building (and after
deleting the other flavour).
- If you are cross building, use the "cross" build-profile.
- You can skip building user-space packages by using the
"pkg.linux.notools" build profile. (Without that, cross-build-
dependencies may often be unsatisfiable due to version skew.)
OK, thanks a lot, this is very useful to know.
But just to clarify, can I just apply this to the current latest Debian package, run debian/rules debian/control-real and build the package
normally?
Sorry, if that's too obvious, I just want to avoid producing noise.
OK, thanks a lot, this is very useful to know.
But just to clarify, can I just apply this to the current latest Debian package, run debian/rules debian/control-real and build the package normally?
Sorry, if that's too obvious, I just want to avoid producing noise.
You can apply it to the latest version in experimental, yes.
On Wed, 2024-09-11 at 16:55 +0200, Ben Hutchings wrote:
OK, thanks a lot, this is very useful to know.
But just to clarify, can I just apply this to the current latest Debian package, run debian/rules debian/control-real and build the package normally?
Sorry, if that's too obvious, I just want to avoid producing noise.
You can apply it to the latest version in experimental, yes.
Thanks! Will give it a try.
Hi Ben,
On Wed, 2024-09-11 at 17:14 +0200, John Paul Adrian Glaubitz wrote:
On Wed, 2024-09-11 at 16:55 +0200, Ben Hutchings wrote:
OK, thanks a lot, this is very useful to know.
But just to clarify, can I just apply this to the current latest Debian package, run debian/rules debian/control-real and build the package normally?
Sorry, if that's too obvious, I just want to avoid producing noise.
You can apply it to the latest version in experimental, yes.
Thanks! Will give it a try.
Just as a heads-up: I need a few more days as my sh4 builder is currently busy
with some GCC test builds ahead of the GCC SH LRA transition. I will test your
patch set as soon as possible and definitely before the end of next week.
I've done a new cross-build here, so you can test the packages from: https://people.debian.org/~benh/packages/linux-sh4/
On Sun, 2024-09-15 at 00:10 +0200, Ben Hutchings wrote:[...]
I've done a new cross-build here, so you can test the packages from: https://people.debian.org/~benh/packages/linux-sh4/
Thanks a lot.
I installed the new kernel package and it seems it won't work as it's not
an U-Boot image as required but just a plain compressed kernel image:
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 148:32:56 |
| Calls: | 10,383 |
| Calls today: | 8 |
| Files: | 14,054 |
| D/L today: |
2 files (1,861K bytes) |
| Messages: | 6,417,747 |