On Monday, 24 June 2024 07:10:48 CEST Leith Bade wrote: > I finished my first round of testing the new kerned on my BPI-R3 board.
This is more extensive testing then I normally see. Nice :-)
> This likely due to my unfamiliarity with building the Debian kernel.
Given your interest (similar to mine ~2 y/o) and skill set (higher then mine),
it's probably worth learning that ;-)
> So instead after constructing a working testing/sid root filesystem on an
> SD card via debootstrap I have installed and tested a v6.10 kernel build
> that Diederik supplies me with. The kernel version string for this is:
> Linux version 6.10-rc3+unreleased-arm64 (debian-ker...@lists.debian.org)
> (aarch64-linux-gnu-gcc-13 (Debian 13.2.0-25) 13.2.0, GNU ld (GNU Binutils
> for Debian) 2.42) #1 SMP Debian 6.10~rc3-1~cknow (2024-04-24)
I plan to build a 6.10~rc5 soon ...
> The device tree is a modified version of the
> upstream linux device tree file "mediatek/mt7986a-bananapi-bpi-r3.dtb"
Can you share those changes? I analyzed and enabled modules purely on what's
available upstream.
> The device tree requires applying various overlay files
> ("mt7986a-bananapi-bpi-r3-nor.dtbo", "mt7986a-bananapi-bpi-r3-nand.dtbo",
> "mediatek/mt7986a-bananapi-bpi-r3-sd.dtbo",
> "mediatek/mt7986a-bananapi-bpi-r3-emmc.dtbo") to select the correct
> configuration for the attached storage chips. These chips are
> enabled/disabled by the boot selection DIP switch labelled "SW1" on the
> board. You can choose between the NOR or NAND chip, as well as the SD card
> slot or eMMC chip. So the combinations are: NOR + SD, NOR + eMMC, NAND +
> SD, NAND + eMMC. Since I was booting from an SD card I have not yet tested
> the eMMC chip.
I forgot to analyze the dtbo files and consequently added the needed kernel
modules for it. Will include that in my 6.10~rc5 build.
> The kernel boots successfully and I make it all the way to the login screen
> via serial as well as the SSH server working.
\o/
> All tested devices work except for:
>
> SoC Hardware Accelerated Cryptography
> Device Tree name: "crypto: crypto@10320000"
> DT compatible: "inside-secure,safexcel-eip97"
> Issue:
>
> In the kernel dmesg boot log there are a variety of errors like:
> > [ 8.910388] alg: ahash: safexcel-sha384 test failed (wrong result) on
> > test vector 1, cfg="init+update+final aligned buffer"
> > [ 8.921577] alg: self-tests for sha384 using safexcel-sha384 failed
> > (rc=-22)
>
> These errors are repeated for: "safexcel-sha384" "safexcel-sha512"
> "safexcel-hmac-sha384" "safexcel-hmac-sha512"
> ...
> I did not see this error in the Ubuntu v6.8 kernel, so I will be interested
> to test the Debian v6.8 kernel once I get it building to see if this is a
> regression in the v6.10 kernel.
There have been *no* upstream commits to ``drivers/crypto/inside-secure/``
since 6.8, so that would surprise me. Possible causes:
- Ubuntu has a patch for this
- Ubuntu's kernel config enables options which the Debian kernel doesn't
The latter is more likely, which can mean that upstream's kernel module is
missing some depends/selects? This is speculation though.
> SoC SNFI Serial Flash Bus
> ...
> The fix here is to build the "spi-mtk-snfi" module from the MTD drivers.
Ack. CONFIG_SPI_MTK_SNFI (tristate)
> SPIM NAND Chip
> ...
> The fix here is to build the "spi-nand" module from the MTD drivers.
Ack. CONFIG_MTD_SPI_NAND (tristate)
> SFP RJ45 2.5 GbE Modules
> ...
> kernel finds them in the boot log:
> > [ 2.744506] sfp sfp-1: Host maximum power 3.0W
> > [ 2.768976] sfp sfp-2: Host maximum power 3.0W
> > [ 3.105275] sfp sfp-2: module OEM SFP-2.5G-T-R-RM rev
> > 1.0 sn 2405070133 dc 240507
> > [ 3.135654] sfp sfp-1: module OEM SFP-2.5G-T-R-RM rev
> > 1.0 sn 2405070134 dc 240507
>
> But the resulting eth0/eth1 devices do not work. Searching on the Banana Pi
> forum, and then the kernel net mailing list it appears that patches to
> support these devices have not yet been accepted upstream.
Note that for inclusion in the Debian kernel the device should be *usable*.
It does not require that everything works perfectly.
If you learn to build a Debian kernel, there's ``debian/patches`` where you
could put those patches in so they get included in your build. You could then
share your test finding with the upstream discussion of those patches and
ideally add a "Tested-by: you <your@email.address>" which helps to get things
merged upstream (which then will find its way into a future Debian kernel)
> 2.4 GHz & 5 GHz WiFi
> Device Tree name: "wifi: wifi@18000000"
> DT compatible: "mediatek,mt7986-wmac"
> Issue:
> Initially the kernel boot log was saying the required firmware files could
> not be found:
> ...
> > [ 33.775740] mt798x-wmac 18000000.wifi: probe with driver mt798x-wmac
> > failed with error -110
>
> I then installed the "linux-firmware" package from testing/sid APT
... so close ...
> repository, but the error message persisted. Additionally I saw this
>
> message from update-initramfs:
> > update-initramfs: Generating /boot/initrd.img-6.10-rc3+unreleased-arm64
> > W: Possible missing firmware /lib/firmware/mediatek/mt7988_wo_1.bin for
> > module mtk_eth
>
> After inspecting the /lib/firmware directory, it seems the APT package
> "firmware-misc-nonfree" has firmware for older MediaTek chips, but is
> missing files for ant MT79xx including MT7981 and MT7986.
d1c24e6cfa18 ("mediatek: Synchronize with 20230625's WHENCE file")
added those files and has been released to *experimental* in version
20230625-3~exp2. You'd need the firmware-mediatek package though.
> So in summary:
> - need to enable building of the "spi-mtk-snfi" and "spi-nand" kernel
> modules to support all the flash chips you can use with MT7986
will be available in my next build
> - need to update the Debian "firmware-misc-nonfree" to add the missing
> MT79xx firmware files
install firmware-mediatek from experimental
> - possible regression from kernel v6.8 to v6.10 that breaks support for the
> "inside-secure,safexcel-eip97" crypto device - I need to get a working
> Debian v6.8 kernel build to confirm
Even though I found no upstream changes in ``drivers/crypto/inside-secure/``
it could be that a changes somewhere else did cause a regression.
So trying it with a 6.8 Debian kernel is useful.
> - don't plug in a non-FTDI chip based USB-to-serial cable into the UART0
> port otherwise WiFi will not work
I'm still missing a "Tested-by:" tag for my changes ;-P
Cheers,
Diederik
signature.asc
Description: This is a digitally signed message part.
