Hi,

Debian provides a kernel for Raspberry Pi Zero (W) and 1, but that targets
the armel architecture. I want to compile a/the Debian kernel that does use the HW capabilities of the RPi 0/1, similarly to how raspbian.org recompiles
the Debian packages. Except AFAIK the Debian kernel.

I know that Debian won't change their RPi kernel for armel, but this is for private use. But I don't know what the best way to go about that is.

I found the following link wrt building a cross compiler https://solarianprogrammer.com/2018/05/06/building-gcc-cross-compiler-raspberry-pi/
which in turn references https://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/
and that does look promising.

But before diving full into it, I'd like to know whether this is the proper approach or not. And if someone has good/better links, I'd appreciate it if you'd share them :-)

While I (technically) could setup a system to compile natively, I want to use cross compilation (on amd64 PC). I think it would otherwise take days.
But knowing how to compile natively would be nice too.
I do know how to compile Debian's kernels, both natively and cross building.

Cheers,
Diederik
-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY1WkRQAKCRDXblvOeH7b bufqAP4yDCBJoOXogeuLpae+t2isKY5u7E3kYMERbPsa+7PzsQD/UyGqKj5YDeSq CnzuYoHpUfj22x4cFsGcWCGzs79qrAI=
=dQm0
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/23/22 16:31, Diederik de Haas wrote:

Hi,

Debian provides a kernel for Raspberry Pi Zero (W) and 1, but that targets the armel architecture. I want to compile a/the Debian kernel that does use the
HW capabilities of the RPi 0/1, similarly to how raspbian.org recompiles
the Debian packages. Except AFAIK the Debian kernel.

I know that Debian won't change their RPi kernel for armel, but this is for private use. But I don't know what the best way to go about that is.

I found the following link wrt building a cross compiler https://solarianprogrammer.com/2018/05/06/building-gcc-cross-compiler-raspberry-pi/
which in turn references https://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/
and that does look promising.

But before diving full into it, I'd like to know whether this is the proper approach or not. And if someone has good/better links, I'd appreciate it if you'd share them :-)

While I (technically) could setup a system to compile natively, I want to use cross compilation (on amd64 PC). I think it would otherwise take days.

Probably an over estimate unless you don't have any SSD hardware for
workspace.
 I do, 240Gigs on a startech usb to sata adaptor  and I have built an
armhf version
of 4.19 in under an hour on an rpi4. Working on a u-sd card,
you'll be abusing the card and quite a few hours. I would not even try
it on less than a 64G u-sd.
You'll surely kill an 8G u-sd card by writing it to death..

But knowing how to compile natively would be nice too.
I do know how to compile Debian's kernels, both natively and cross building.

Cheers,
Diederik

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Diederik de Haas <[email protected]> writes:

Hi,

Debian provides a kernel for Raspberry Pi Zero (W) and 1, but that targets the armel architecture. I want to compile a/the Debian kernel that does use the
HW capabilities of the RPi 0/1, similarly to how raspbian.org recompiles
the Debian packages. Except AFAIK the Debian kernel.

I know that Debian won't change their RPi kernel for armel, but this is for private use. But I don't know what the best way to go about that is.

I found the following link wrt building a cross compiler https://solarianprogrammer.com/2018/05/06/building-gcc-cross-compiler-raspberry-pi/
which in turn references https://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/
and that does look promising.

I am probably missing some context but I wanted to point to the armel
cross compiler in Debian - gcc-arm-linux-gnueabi. Is there some reason
to build the cross-compiler yourself?

[...]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: [email protected]

On maandag 24 oktober 2022 11:16:42 CEST Punit Agrawal wrote:

I am probably missing some context but I wanted to point to the armel
cross compiler in Debian - gcc-arm-linux-gnueabi. Is there some reason
to build the cross-compiler yourself?

I don't want to build for armel, but for raspbian.org's variant of armhf,
which is not the same as Debian's armhf.
The RPi 0/1 fall somewhere in the middle of Debian's armel and armhf and
that's the whole reason raspbian.org was created.

But it can be that I'm looking at this problem all wrong and/or have some tunnel vision towards building a cross compiler.
That is an important reason for making this ML thread.

Cheers,
Diederik
-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY1Z/dAAKCRDXblvOeH7b bsgbAP4kuv0E/dtahFYbGAbedjNhsGVBX6Z3OY5DQoPWgLJTMQEAlMyuwwqn0HG+ jGCgxiTsocRA2CjPEveLEWfvpThZrQ4=
=LeHZ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Diederik de Haas <[email protected]> writes:

On maandag 24 oktober 2022 11:16:42 CEST Punit Agrawal wrote:

I am probably missing some context but I wanted to point to the armel
cross compiler in Debian - gcc-arm-linux-gnueabi. Is there some reason
to build the cross-compiler yourself?

I don't want to build for armel, but for raspbian.org's variant of armhf, which is not the same as Debian's armhf.
The RPi 0/1 fall somewhere in the middle of Debian's armel and armhf and that's the whole reason raspbian.org was created.

Thanks for the context.

But it can be that I'm looking at this problem all wrong and/or have some tunnel vision towards building a cross compiler.
That is an important reason for making this ML thread.

IIUC, for the kernel, either compiler should be fine. The
documentation[0] for compiling the RPi Zero kernel seems to bear this
out - it even uses the "CROSS_COMPILE=arm-linux-gnueabihf-". If you've
got access to the hardware it should be easy to test before kicking off
the Debian kernel package build.

Hope that helps.

Regards,
Punit

[0] https://www.raspberrypi.com/documentation/computers/linux_kernel.html#cross-compiling-the-kernel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Oct 25, 2022 at 09:12:06AM +0200, Marcin Juszkiewicz wrote:

W dniu 25.10.2022 o�00:03, Punit Agrawal pisze:

IIUC, for the kernel, either compiler should be fine. The
documentation[0] for compiling the RPi Zero kernel seems to bear this
out - it even uses the "CROSS_COMPILE=arm-linux-gnueabihf-". If you've
got access to the hardware it should be easy to test before kicking off
the Debian kernel package build.

Raspbian uses own definition of armhf (armv6) while Debian (and other distros) use armv7 for armhf.

So using any documentation which mentions armhf and r/pi needs to be done in careful way.

The (early) Raspberry Pi 0/1 (and the Pi Zero v1 at least) are armv6 with hardware floating point when all the Linux distributions had already
decided on v7 and hardware floating point as armhf architecture.
Debian armel runs fine without recompilation at a slight penalty.

Raspbian history is effectively a port by interested Debian folk -
Raspberry Pi OS is subtly different (and includes non-free software
as part of the standard build).

Later models of Raspberry Pi run as v7 and hardware floating point so
Debian armhf runs natively.

Raspberry Pi OS is slowly moving to 64 bit but the earliest Pis are 32 bit only. Debian arm64 will run natively on Raspberry Pi 64 bit - the latest firmware vote will also mean that we can include Raspberry Pi firmware
in the installer for next version Bookworm.

Hope this helps,

Andy Cater

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

W dniu 25.10.2022 o 00:03, Punit Agrawal pisze:

IIUC, for the kernel, either compiler should be fine. The
documentation[0] for compiling the RPi Zero kernel seems to bear this
out - it even uses the "CROSS_COMPILE=arm-linux-gnueabihf-". If you've
got access to the hardware it should be easy to test before kicking off
the Debian kernel package build.

Raspbian uses own definition of armhf (armv6) while Debian (and other
distros) use armv7 for armhf.

So using any documentation which mentions armhf and r/pi needs to be
done in careful way.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Oct 25, 2022, at 00:03, Punit Agrawal wrote:

Diederik de Haas <[email protected]> writes:

But it can be that I'm looking at this problem all wrong and/or have some
tunnel vision towards building a cross compiler.
That is an important reason for making this ML thread.

IIUC, for the kernel, either compiler should be fine. The
documentation[0] for compiling the RPi Zero kernel seems to bear this
out - it even uses the "CROSS_COMPILE=arm-linux-gnueabihf-". If you've
got access to the hardware it should be easy to test before kicking off
the Debian kernel package build.

That is correct: it's the same compiler backend, the only difference
between an arm-linux-gnuabihf- and an arm-linux-gnueabi- toolchain are
which CPU and floating pointing ABI are set when building with the
default flags. The kernel itself is always built as soft-float even
for armv7 using an armhf toolchain, and the CPU is always set to
the minimum configured target machine, so both compilers will produce
the same kernel binary.

Note that at the moment, you can build a kernel that works on
both armv6 and armv7 CPUs, or armv7 and armv8, but not armv5
and armv6/v7, or armv6 and armv8, and this limits what machines
can be enabled in a single kernel. I have a prototype kernel
patch that intends to change the way we build armv6 kernels,
so one can actually enable armv6 non-SMP support (Raspberry
Pi 0/1, OMAP2, i.MX3, s3c64xx, ...) in the default armel
kernel along with the ARMv5 targets (orion, kirkwood, pxa,
at91, omap1, imx2, suniv, ...), but no longer with ARMv7.

Arnd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Oct 25, 2022, at 11:15, Diederik de Haas wrote:

On Tuesday, 25 October 2022 10:02:09 CEST Andrew M.A. Cater wrote:

Debian armel runs fine without recompilation at a slight penalty.

It is exactly this 'slight penalty' that I want to verify.

I have a Zero W running Debian's armel kernel and I find that device to be annoyingly slow.
I also have a RPi 1 running raspbian.org's 4.9 kernel, which is a special kernel build by plugwash and compiled like the rest of raspbian.org packages, which I do not find (annoyingly) slow.

The difference between the two kernels is almost certainly unrelated
to the toolchain they are built with, and entirely based on the
kernel patches that are added on top of mainline as well as the
configuration.

If there is a huge difference, my first guess would be the CPU frequency scaling driver: if the CPU runs a different operating point, that
would have a much larger impact than anything the kernel itself
can do. Another obvious difference may be the GPU support: if you
the HDMI output, having an accelerated driver for it will feel
much faster than running on a plain framebuffer.

If you have a fast Raspbian kernel and a slow Debian kernel for
the same source version, can you take a look at the /boot/config-*
files, and the list of loaded kernel modules, to see if there
are any obvious differences?

Arnd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, 25 October 2022 10:02:09 CEST Andrew M.A. Cater wrote:

Debian armel runs fine without recompilation at a slight penalty.

It is exactly this 'slight penalty' that I want to verify.

I have a Zero W running Debian's armel kernel and I find that device to be annoyingly slow.
I also have a RPi 1 running raspbian.org's 4.9 kernel, which is a special kernel build by plugwash and compiled like the rest of raspbian.org packages, which I do not find (annoyingly) slow.
-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY1epIwAKCRDXblvOeH7b boqBAQD17Cx0+nEZPCCXkS3H6+eS9PSCp38hXtJk0sjl9/3JcQD9En1eAKj4UfJP Mw7qSBWgxXMEGttatm5B05tUSRVd9AQ=
=YomG
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.

--nextPart45048445.fMDQidcC6G
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Tuesday, 25 October 2022 14:34:12 CEST Diederik de Haas wrote:

and entirely based on the kernel patches that are added on top of mainline as well as the configuration.

The patch set may be more substantial then I initially thought.
In 2015 I asked plugwash the general procedure to make a raspbian.org style kernel and my notes of that are attached.

Through that, I found that an 'update-rpi-patches' script was used (attached) and that adds https://github.com/raspberrypi/linux.git as remote.

I don't think I ever succeeded in building such a kernel though, probably also because I had ~0 experience with building a kernel at all. --nextPart45048445.fMDQidcC6G
Content-Disposition: attachment; filename="Making a raspbian.org style kernel.txt"
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="UTF-8"; name="Making a raspbian.org style kernel.txt"

Making a raspbian.org style kernel

https://plugwash.raspbian.org/linux_3.18/ https://sourcearchive.raspbian.org/main/l/linux/

1: take the debdiff
2: filter out debian/patches using filterdiff
3: apply the filtered debdiff to a Debian source package for the correct major version
4: deal with any bits of the patch that failed to apply
5: update the settings in debian/update-rpi-patches
6: make debian/update-rpi-patches executable (since diff/patch don't preserve permissions)
7: run debian/update-rpi-patches
8: try and work out what new config settings are needed from diffing the two major versions in the rpf repo, edit debian/config/armhf/config.rpi (I think that is the name, I may be misremembering) accordingly
9: hack away at the package until it builds successfully
10: build the package
11: test the kernel actually boots, if not hack on things some more until it does

ad 1)
debdiff between the raspbian kernel package and the debian kernel package it's based on.
debdiff linux_3.18.5-1~exp1.dsc linux-3.18_3.18.5-1~exp1+rpi20.dsc > linux-3.18.debdiff
Obtained the linux_3.18.5-1~exp1.dsc file through snapshot.debian.org (http://snapshot.debian.org/archive/debian/20150208T160746Z/pool/main/l/linux/)
Besides the .dsc file you also need the .orig.tar.xz file and the .debian.tar.xz file

ad 2)
filterdiff -p1 -x 'debian/patches/*' linux-3.18.debdiff > linux-3.18.debdiff.filtered

ad 7)
oh another thing, update-rpi-patches will run much faster if you have a clone of the rpi kernel tree in a directory called linuxgit in the parent of the directory where you have the package source extracted
--nextPart45048445.fMDQidcC6G
Content-Disposition: attachment; filename="update-rpi-patches" Content-Transfer-Encoding: base64
Content-Type: application/x-shellscript; name="update-rpi-patches"

IyEvYmluL2Jhc2ggLWV2CnNldCAteApzZXQgLWUKZGViZGlyPWBwd2RgCnVwc3RyZWFtX3RhZz12 My4xOC41CnJwaV9icmFuY2g9cnBpLTMuMTgueQpycGlfdHJlZT1ycGkvJHtycGlfYnJhbmNofQoj cnBpX3RyZWU9YmI2YjRiNmIzMzE2ODBiZWQ4MDc2MDU2ODU1NzJkNzI3NjM4YmI1MQpwYXRjaF9k aXI9JHtkZWJkaXJ9L2RlYmlhbi9wYXRjaGVzCnJwaV9wYXRjaGVzPSR7cGF0Y2hfZGlyfS9ycGkK dXBzdHJlYW1fZ2l0cmVwbz1naXQ6Ly9naXQua2VybmVsLm9yZy9wdWIvc2NtL2xpbnV4L2tlcm5l bC9naXQvc3RhYmxlL2xpbnV4LXN0YWJsZS5naXQKI2Nhbm9uaWNhbCBnaXQgcmVwbyBmb3IgY2t0 ICJ1cHN0cmVhbSIgcmVsZWFzZXMKI3Vwc3RyZWFtX2dpdHJlcG89Z2l0Oi8va2VybmVsLnVidW50 dS5jb20vdWJ1bnR1L2xpbnV4LmdpdAoKI21ha2UgYSBiYWNrdXAgb2YgdGhlIHF1aWx0IHNlcmll cyBzbyB0aGUgdXNlciBjYW4gcmVzdG9yZSBpdCBpZiB0aGlzIHNjcmlwdCBmYWlscwpjcCBkZWJp YW4vcGF0Y2hlcy9zZXJpZXMgZGViaWFuL3BhdGNoZXMvc2VyaWVzLmJhawoKZXhwb3J0IFFVSUxU X1BBVENIRVM9ZGViaWFuL3BhdGNoZXMKcXVpbHQgcG9wIC1hIHx8IFsgJD8gPT0gMiBdCgogIyBh ZGQgcmVtcG90ZSByZXBvc2l0b3JpZXMsIGFuZCB1cGRhdGUgKG5lZWRzIGEgYXJvdW5kIDUwME0p CnJtIC1yZiBsaW51eGdpdApnaXQgY2xvbmUgLW8gbGludXgtc3RhYmxlIC0tcmVmZXJlbmNlIC4u L2xpbnV4Z2l0ICR7dXBzdHJlYW1fZ2l0cmVwb30gbGludXhnaXQKCmNkIGxpbnV4Z2l0CmdpdCBy ZW1vdGUgYWRkIHJwaSBodHRwczovL2dpdGh1Yi5jb20vcmFzcGJlcnJ5cGkvbGludXguZ2l0Cmdp dCByZW1vdGUgdXBkYXRlCgogIyBjcmVhdGUgYnJhbmNoIGZyb20gdGFnIGFuZCBzd2l0Y2ggdG8g aXQKZ2l0IGNoZWNrb3V0IC1iIHRhcmdldC12ZXJzaW9uICR7dXBzdHJlYW1fdGFnfQoKIyByZWNv cmQgY29tbWl0cyB1c2VkIHRvIGJhc2UgcGF0Y2hlcyBvbgpnaXQgc2hvdyAke3Vwc3RyZWFtX3Rh Z30gPiAuLi9kZWJpYW4vdXBzdHJlYW0tdGFnLXVzZWQtdG8tZ2VuZXJhdGUtcnBpLXBhdGNoZXMK Z2l0IHNob3cgJHtycGlfdHJlZX0gPiAuLi9kZWJpYW4vcnBpLWJyYW5jaAoKIyBtZXJnZSB0aGUg Y2hhbmdlcyBmcm9tIHRoZSBycGkgYnJhbmNoCmdpdCBtZXJnZSAtLW5vLWVkaXQgJHtycGlfdHJl ZX0KCiMgZ2V0IGEgbGlzdCBvZiBjb21taXRzIG5vdCBwcmVzZW50IHVwc3RyZWFtCmdpdF9jb21t aXRzPSQoZ2l0IGNoZXJyeSAke3Vwc3RyZWFtX3RhZ30gfCBhd2sgJy9eXCsve3ByaW50ICQyfScp CgojIFJlbW92ZSBjb21taXQgYTVmMTk2Y2E5MGE3MTdjMGM0MGMzM2M0Y2E4MTVjNmM2MDZkMTlj MiwgaXQgc2VlbXMgdG8gYWxyZWFkeSBiZSBhcHBsaWVkIGluIHRoZSBkZWJpYW4gInVwc3RyZWFt IiBzb3VyY2UuCgpnaXRfY29tbWl0cz1gZWNobyAke2dpdF9jb21taXRzfSB8IHNlZCBzL2E1ZjE5 NmNhOTBhNzE3YzBjNDBjMzNjNGNhODE1YzZjNjA2ZDE5YzIvL2AKCiMgZ2VuZXJhdGUgb25lIHBh dGNoIHBlciBjb21taXQsIGluY2x1ZGluZyBjb21tZW50cywgd2l0aCBhbiBvcmRlcmVkIHNlcXVl bmNlCiMgdG8gcHJlc2VydmUgcGF0Y2ggb3JkZXJpbmcuCmk9MTAwMApybSAtcmYgJHtycGlfcGF0 Y2hlc30KbWtkaXIgLXAgJHtycGlfcGF0Y2hlc30KZm9yIGMgaW4gJGdpdF9jb21taXRzIDsgZG8K ICAgIGdpdCBzaG93ICR7Y30gPiAke3JwaV9wYXRjaGVzfS9ycGlfJHtpfV8ke2N9LnBhdGNoCiAg ICAjIGluY2x1ZGUgZHVtbXkgZmlsZSBpbiBwYXRjaCB0byBlbnN1cmUgaXQgaGFzIHNvbWUgY29u dGVudCBldmVuIGFmdGVyIGxhdGVyIHByb2Nlc3NpbmcgKGVtcHR5IHBhdGNoZXMgdXBzZXQgcXVp bHQpCiAgICAjZHVtbXkgZnVuY3Rpb25hbGl0eSBkaXNhYmxlZCBmb3Igbm93LCBob3BlZnVsbHkg d2Ugd29uJ3QgbmVlZCBpdCB3aXRoIDMuMTIKICAgICNkdW1teSBmdW5jdGlvbmFsaXR5IHJlZW5h YmxlZCwgc2VlbXMgd2UgZG8gbmVlZCBpdCB3aXRoIGN1cnJlbnQgMy4xOAogICAgY2F0IC4uL2Rl Ymlhbi9wYXRjaGVzL2R1bW15dGVtcGxhdGUuZGlmZiB8IHNlZCBzL1BBVENITkFNRS9ycGlfJHtp fV8ke2N9LyA+PiAke3JwaV9wYXRjaGVzfS9ycGlfJHtpfV8ke2N9LnBhdGNoCiAgICBpPSQoKCR7 aX0rMSkpCmRvbmUKCiNwaXBlIHRoZSBvdXRwdXQgb2YgZ2l0IGRpZmYgdGhyb3VnaCBmaWx0ZXJk aWZmIGFzIGl0IHNlZW1zIHRvIGNvbmZ1c2UgaW50ZXJkaWZmIG90aGVyd2lzZQpnaXQgZGlmZiAk e3Vwc3RyZWFtX3RhZ30gfCBmaWx0ZXJkaWZmID4gLi4vbWVyZ2VkLmRpZmYKZXhwb3J0IFFVSUxU X1BBVENIRVM9Li4vZGViaWFuL3BhdGNoZXMKCiMgc3BsaXQgcXVpbHQgc2VyaWVzIGFuZCByZW1v dmUgcGkgcGF0Y2hlcwpjZCAuLgpjaG1vZCA3NTUgZGViaWFuL3NwbGl0c2VyaWVzLnBocApkZWJp YW4vc3BsaXRzZXJpZXMucGhwCmNkIGxpbnV4Z2l0CgojIGNyZWF0ZSBuZXcgcXVpbHQgc2VyaWVz LCB1c2UganVzdCB0aGUgbmV3IHNlcmllcyBmb3Igbm93IGZvciB0ZXN0aW5nCmxzICR7cnBpX3Bh dGNoZXN9IHwgc2VkIHNfXl9ycGkvXyA+ICR7cGF0Y2hfZGlyfS9zZXJpZXMuZnJvbWdpdApjcCAk e3BhdGNoX2Rpcn0vc2VyaWVzLmZyb21naXQgJHtwYXRjaF9kaXJ9L3NlcmllcwoKZ2l0IHJlc2V0 IC0taGFyZCAke3Vwc3RyZWFtX3RhZ30KY2QgLi4KCnJtIC1yZiBsaW51eHRlc3QgbGludXhjbGVh bgoKcnN5bmMgLWEgLS1leGNsdWRlIC5naXQgbGludXhnaXQvIGxpbnV4dGVzdC8KY3AgLWFsIGxp bnV4Z2l0IGxpbnV4Y2xlYW4Kcm0gLXJmIGxpbnV4Y2xlYW4vLmdpdAoKY2QgbGludXh0ZXN0CmV4 cG9ydCBRVUlMVF9QQVRDSEVTPS4uL2RlYmlhbi9wYXRjaGVzCnF1aWx0IHB1c2ggLWEgfHwgdHJ1 ZQp3aGlsZSBxdWlsdCBwdXNoIC1mIHx8IFsgJD8gPT0gMSBdOyBkbyAKCXF1aWx0IHJlZnJlc2gK CXF1aWx0IHB1c2ggLWEgfHwgdHJ1ZQpkb25lCmNkIC4uCgpkaWZmIC11ck4gbGludXhjbGVhbiBs aW51eHRlc3QgfCBmaWx0ZXJkaWZmIC1wMSAteCAnLnBjLyonIC14ICdkdW1teS8qJyAtLWNsZWFu ID4gcGF0Y2hlZC5kaWZmIHx8IFsgJD8gPT0gMSBdCmVjaG8gJ3RoaXMgcGF0Y2ggY29udGFpbnMg Y2hhbmdlcyB0aGF0IHRoZSBzeXN0ZW0gY291bGQgbm90IHNwbGl0IG91dCBpbnRvIGluZGl2aWR1 YWwgcGF0Y2hlcycgPiBkZWJpYW4vcGF0Y2hlcy9ycGkvcnBpXzk5OTlfb3RoZXJfY2hhbmdlcy5w YXRjaAppbnRlcmRpZmYgLXAxIHBhdGNoZWQuZGlmZiBtZXJnZWQuZGlmZiB8IGZpbHRlcmRpZmYg LXggJyoucmVqJyAtLWNsZWFuID4+IGRlYmlhbi9wYXRjaGVzL3JwaS9ycGlfOTk5OV9vdGhlcl9j aGFuZ2VzLnBhdGNoCmNhdCBkZWJpYW4vZHVtbXkucGF0Y2ggPj4gZGViaWFuL3BhdGNoZXMvcnBp L3JwaV85OTk5X290aGVyX2NoYW5nZXMucGF0Y2gKZWNobyBycGkvcnBpXzk5OTlfb3RoZXJfY2hh bmdlcy5wYXRjaCA+PiAke3BhdGNoX2Rpcn0vc2VyaWVzLmZyb21naXQKCiNyZWFzc2VtYmxlIGZ1 bGwgcXVpbHQgIHNlcmllcwpjYXQgJHtwYXRjaF9kaXJ9L3Nlcmllcy5wcmVmaXggJHtwYXRjaF9k aXJ9L3Nlcmllcy5mcm9tZ2l0ICR7cGF0Y2hfZGlyfS9zZXJpZXMuc3VmZml4ID4gJHtwYXRjaF9k aXJ9L3NlcmllcwoKCgpleHBvcnQgUVVJTFRfUEFUQ0hFUz1kZWJpYW4vcGF0Y2hlcwpxdWlsdCBw dXNoIC1hIC0tZnV6eiAwIHx8IHRydWUKd2hpbGUgcXVpbHQgcHVzaDsgZG8KCXF1aWx0IHJlZnJl c2gKCXF1aWx0IHB1c2ggLWEgLS1mdXp6IDAgfHwgdHJ1ZQpkb25lCgpybSAtcmYgbGludXhnaXQg bGludXhjbGVhbiBsaW51eHRlc3QKcm0gbWVyZ2VkLmRpZmYgcGF0Y2hlZC5kaWZmCnJtIGRlYmlh bi9wYXRjaGVzL3Nlcmllcy4qCgplY2hvIGZpbmlzaGVkIHN1Y2Vzc2Z1bGx5Cgo=


--nextPart45048445.fMDQidcC6G--

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY1fbJwAKCRDXblvOeH7b brWqAQD0OM3TJNErotrMDN2HdvB6QzPKVZ++ctWIEkMzuTNE0gD/YgTJ7dXe3miy ZkAaI5mX94u7lt/rZy74egFl4JnUJgM=
=TV5+
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, 25 October 2022 11:33:40 CEST Arnd Bergmann wrote:

IIUC, for the kernel, either compiler should be fine. The
documentation[0] for compiling the RPi Zero kernel seems to bear this
out - it even uses the "CROSS_COMPILE=arm-linux-gnueabihf-". If you've
got access to the hardware it should be easy to test before kicking off
the Debian kernel package build.

How can I test that? I'm not a C programmer and I thought that crashes due to arch differences would only manifest themselves under certain circumstances which could take a while to manifest.

That is correct: it's the same compiler backend, the only difference
between an arm-linux-gnuabihf- and an arm-linux-gnueabi- toolchain are
which CPU and floating pointing ABI are set when building with the
default flags. The kernel itself is always built as soft-float even
for armv7 using an armhf toolchain, and the CPU is always set to
the minimum configured target machine, so both compilers will produce
the same kernel binary.

So this means I *can* actually use the arm-linux-gnuabihf compiler* already available in the Debian archives? I did not expect that as I _assumed_ it
would make binaries for Debian's armhf architecture.

*) I normally don't take things RPi Foundation puts out at face value -----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY1fSdwAKCRDXblvOeH7b bp43AP9WqXciWUfTzxNKDMGVH/Qy6lA1bOgmZ2vj9g9KG3XL0wEAnsyy+YNCbecj 62YCU1aWf2MpIhv0LJ4BmhzP5OJurgw=
=A17T
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, 25 October 2022 12:01:01 CEST Arnd Bergmann wrote:

I have a Zero W running Debian's armel kernel and I find that device to be annoyingly slow.
I also have a RPi 1 running raspbian.org's 4.9 kernel, which is a special kernel build by plugwash and compiled like the rest of raspbian.org packages, which I do not find (annoyingly) slow.

The difference between the two kernels is almost certainly unrelated
to the toolchain they are built with,

That surprises me as I thought that raspbian.org's effort (and reason for existing at all) was entirely based on that.

and entirely based on the kernel patches that are added on top of mainline
as well as the configuration.

If there is a huge difference, my first guess would be the CPU frequency scaling driver: if the CPU runs a different operating point, that
would have a much larger impact than anything the kernel itself
can do.

In https://salsa.debian.org/kernel-team/linux/-/merge_requests/381 I did
enable the needed components for that. I will try whether the performance governor makes a notable difference.
RPi 1 only has 1 frequency, but RPi 0 has 2.

Another obvious difference may be the GPU support

They are both used headlessly, so that should be irrelevant.
The RPi 0W is attached to my smart energy meter and the RPi 1 I essentially only use(d) for development purposes.

If you have a fast Raspbian kernel and a slow Debian kernel for
the same source version, can you take a look at the /boot/config-*
files, and the list of loaded kernel modules, to see if there
are any obvious differences?

Can `=m` vs `=y` have a (relevant) impact?
I will ofc compare them, but I have already looked (a while ago) at the config for obvious missing components and only found 1 which is now fixed: https://salsa.debian.org/kernel-team/linux/-/merge_requests/486

Cheers,
Diederik
-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY1fXxAAKCRDXblvOeH7b buAHAP9Y56T/3tzekY9uFIVMw/7WxuWQGxu0YkxnEENiZ91gmgD9FzQE0eEjWmhY YkEyn4XDnAMoob8c200BjKOvTs9VagQ=
=YH+l
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)