Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
That is great news, I will install it once it has been uploaded.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
Control: tag -1 pending On Friday, 28 June 2024 08:47:52 CEST Diederik de Haas wrote: > Control: tag -1 patch > > I submitted a MR to fix this bug with my changes here: > https://salsa.debian.org/kernel-team/linux/-/merge_requests/1109 And that MR has been merged into master and thus should land in the next 6.10 upload \o/ signature.asc Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Wednesday, 12 June 2024 15:59:27 CEST Diederik de Haas wrote: > On Tuesday, 11 June 2024 09:01:20 CEST Diederik de Haas wrote: > > I already have a local branch to add preliminary support for the OpenWrt > > One router [1] [2] which uses the same SoC :-) > > I was wrong. > $ grep ".dtsi" arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts > #include "mt7986a.dtsi" > > $ grep ".dtsi" arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts > #include "mt7981b.dtsi" On the bright side, initial support for OpenWrt One is coming in 6.11 \o/ https://lore.kernel.org/all/20240527115933.7396-1-zaj...@gmail.com/ https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux.git/tag/?h=mtk-dts64-for-v6.11 signature.asc Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
> I submitted a MR to fix this bug with my changes here: > https://salsa.debian.org/kernel-team/linux/-/merge_requests/1109 I just built a linux-image .deb from the MR branch, and after some quick testing everything is working well. So I support this MR getting merged and closing this bug ticket. I still see the crypto boot log error but that shouldn't matter as far as getting the platform supported as only needed for hardware acceleration
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
Control: tag -1 patch On Wednesday, 26 June 2024 03:04:15 CEST Leith Bade wrote: > Diederik provided me with a new v6.10 kernel build to try: > [0.00] Linux version 6.10-rc5+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~rc5-1~cknow (2024-04-24) > > I can confirm the NAND flash chip is now recognised, and shows up in > /dev/mtd*: > [ 11.027448] spi-nand spi0.0: Winbond SPI NAND was found. > [ 11.027469] spi-nand spi0.0: 128 MiB, block size: 128 KiB, page size: > 2048, OOB size: 64 > > I also finished testing the other UART ports on the CON1 header and can > confirm both work. I am working on getting more bits and pieces so I can > test the I2C, SPI, and audio codec pins. I submitted a MR to fix this bug with my changes here: https://salsa.debian.org/kernel-team/linux/-/merge_requests/1109 signature.asc Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
Diederik provided me with a new v6.10 kernel build to try: [0.00] Linux version 6.10-rc5+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~rc5-1~cknow (2024-04-24) I can confirm the NAND flash chip is now recognised, and shows up in /dev/mtd*: [ 11.027448] spi-nand spi0.0: Winbond SPI NAND was found. [ 11.027469] spi-nand spi0.0: 128 MiB, block size: 128 KiB, page size: 2048, OOB size: 64 I also finished testing the other UART ports on the CON1 header and can confirm both work. I am working on getting more bits and pieces so I can test the I2C, SPI, and audio codec pins.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
Thanks, Leith Bade le...@bade.nz On Mon, 24 Jun 2024 at 23:10, Diederik de Haas wrote: > > > > 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. > > > > Yes, I just need to tidy them up into a series of git commits. I don't > > think I had to change anything module related, > > Ok, I use the "compatible" string to figure out what modules are needed. > > I have pushed up what I have to https://github.com/ljbade/linux/tree/bpi-r3-dts There is still some work to be done, but I fixed up most of the device tree schema errors. I also just tested a freshly built .dtb file from the branch after fixing things and I still get the same boot log with the v6.10 rc3 kernel. I did notice an interesting schema error though related to the crypto device: arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: crypto@1032: interrupts: [[0, 116, 4], [0, 117, 4], [0, 118, 4], [0, 119, 4]] is too short from schema $id: http://devicetree.org/schemas/crypto/inside-secure,safexcel.yaml# arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: crypto@1032: interrupt-names: ['ring0', 'ring1', 'ring2', 'ring3'] is too short from schema $id: http://devicetree.org/schemas/crypto/inside-secure,safexcel.yaml# I do not know if this is related to the boot errors I am seeing or not.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Mon, 24 Jun 2024 at 20:32, Diederik de Haas
wrote:
> > 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 ;-)
>
I will eventually manage to figure it out. Part of the problem is that
there is a lot of different advice around the place and a lot of it is out
of date. I can see why the Salsa CI stuff is invaluable here. I wonder if
there is the option to just somehow pay by the cents/hour to rent an arm64
CI node to get it built for me.
> > 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 ...
>
Perfect, I will install that when available.
>
> > 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.
>
Yes, I just need to tidy them up into a series of git commits. I don't
think I had to change anything module related, the main issue was the GPIO
pin conflicts. I plan to coordinate with the original author of the file
(who is on the Banana Pi forum) to work towards getting them submitted to
Linux.
>
> > 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.
>
> Thanks.
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.
>
Interesting. Another possibility is that the self-tests aren't being run
with the Ubuntu kernel. I will do more digging to see what is happening in
Ubuntu.
> 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 " which helps to get
> things
> merged upstream (which then will find its way into a future Debian kernel)
>
Thanks for the advice. The patches I have seen are fairly minor - mainly
adding another special case to match the SFP name string.
I think the upstream concern stems from the way these vendors of these
cheap SFP modules are just programming so many different model strings to
rebadge them as they see fit. There is even a documented case where two
devices from two different vendors have the exact same ID strings, but two
different incompatible PHY chips inside.
The whole string matching thing seems like a mistake to me personally as
these vendors will just end up programming them with whatever string gets
routers (and various Linux forks) to recognise them.
> > 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.
>
Thanks for finding this. The various firmware packages and their differing
names is highly confusing. I wonder if there is some sort of script that
can go find the right packages for your initrd.
>
> > 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
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Monday, 24 June 2024 14:10:18 CEST Leith Bade wrote: > On 24 Jun 2024 at 20:32, Diederik de Haas wrote: > > > This likely due to my unfamiliarity with building the Debian kernel. > > I will eventually manage to figure it out. Part of the problem is that > there is a lot of different advice around the place and a lot of it is out > of date. https://kernel-team.pages.debian.net/kernel-handbook/ or the offline version in the debian-kernel-handbook package *should* give you the proper advice. If not, then that's a bug. > > > 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. > > Yes, I just need to tidy them up into a series of git commits. I don't > think I had to change anything module related, Ok, I use the "compatible" string to figure out what modules are needed. > the main issue was the GPIO pin conflicts. I plan to coordinate with the > original author of the file (who is on the Banana Pi forum) to work towards > getting them submitted to Linux. Awesome > Thanks for the advice. The patches I have seen are fairly minor - mainly > adding another special case to match the SFP name string. > > I think the upstream concern stems from the way these vendors of these > cheap SFP modules are just programming so many different model strings to > rebadge them as they see fit. There is even a documented case where two > devices from two different vendors have the exact same ID strings, but two > different incompatible PHY chips inside. sigh. I can understand upstream's concern. > > I'm still missing a "Tested-by:" tag for my changes ;-P > > Tested-by: Leith Bade Haha, thanks :) Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Monday, 24 June 2024 14:43:38 CEST Leith Bade wrote:
> On Mon, 24 Jun 2024 at 22:10, Leith Bade wrote:
> > > 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.
> >
> > Thanks for finding this. The various firmware packages and their differing
> > names is highly confusing. I wonder if there is some sort of script that
> > can go find the right packages for your initrd.
``apt-file search ``
is the usual way to find which file is in what package
> So I removed linux-firmware-upstream, then installed firmware-mediatek
> from experimental, then did an update-initramfs. After rebooting the WiFi
> is still working.
Cool :)
> What other testing is required before this can make its way into unstable?
I don't know; that's up to the kernel team.
(The above mentioned commit is from me as well as the commit that split out
the mediatek firmware into its own package, but I'm not part of the team)
signature.asc
Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Mon, 24 Jun 2024 at 22:10, Leith Bade wrote:
> > 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.
>>
>
> Thanks for finding this. The various firmware packages and their differing
> names is highly confusing. I wonder if there is some sort of script that
> can go find the right packages for your initrd.
>
So I removed linux-firmware-upstream, then installed firmware-mediatek
from experimental, then did an update-initramfs. After rebooting the WiFi
is still working.
What other testing is required before this can make its way into unstable?
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
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@1032"
> 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 " 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@1800"
> 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 1800.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.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
I finished my first round of testing the new kerned on my BPI-R3 board.
I have had problems trying to get a v6.8 kernel build working from
Dederik's Salsa fork (
https://salsa.debian.org/diederik/linux/-/tree/bananapi-r3-support/debian).
This likely due to my unfamiliarity with building the Debian kernel. It
would be nice if Salsa automatically built the arm64 .deb files but it
seems that is restricted to only certain people because it needs a (rare?)
arm64 CI runner.
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 Dederik 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 booted the kernel via EFI and the next branch of U-boot. I haven't yet
got distro-boot working. The device tree is a modified version of the
upstream linux device tree file "mediatek/mt7986a-bananapi-bpi-r3.dtb"
which fixes a few bugs I have found with the M.2 slot. I also repeated
testing with the unmodified upstream version to verify any problems I found
were not caused by those changes.
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.
So far I have tested all the various onboard connectors/devices except: the
CON1 pins (includes extra UARTs, I2C, SPI, PWM, audio codec pins), the USB2
header pins, mini PCIe slot (USB + SIM only), M.2 slot, eMMC flash chip. I
will work through the remaining connectors once I get what I need to test
them (NVMe SSD, breakout boards, etc).
The kernel boots successfully and I make it all the way to the login screen
via serial as well as the SSH server working. All tested devices work
except for:
SoC Hardware Accelerated Cryptography
Device Tree name: "crypto: crypto@1032"
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"
"safexcel-authenc-hmac-sha512-cbc-aes"
"safexcel-authenc-hmac-sha512-cbc-des3_ede"
"safexcel-authenc-hmac-sha384-cbc-des3_ede"
"safexcel-authenc-hmac-sha512-cbc-des"
"safexcel-authenc-hmac-sha384-cbc-des".
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.
SoC SNFI Serial Flash Bus
Device Tree name: "snand: snfi@11005000"
DT compatible: "mediatek,mt7986-snand"
Issue:
On my board the U14 solder pads for a SNFI chip are unpoplated so this
should remain disabled in the device tree, however the list of build
available kernel modules is missing the driver for this SoC interface. So
if I populated this chip then the device would not work anyway.
The fix here is to build the "spi-mtk-snfi" module from the MTD drivers.
SPIM NAND Chip
Device Tree name: "spi0: spi@1100a000" -> "flash@0"
DT compatible: "spi-nand"
Issue:
When using the NAND DT overlay, the flash device is not loaded due to a
missing module.
The fix here is to build the "spi-nand" module from the MTD drivers.
SFP RJ45 2.5 GbE Modules
Device Tree name: "sfp1: sfp-1" "sfp2: sfp-2"
DT compatible: "sff,sfp"
Issue:
Banana Pi sell some SFP to RJ45 2.5GBASE-T modules on their site advertised
for use with the BPI-R3 board. After plugging them into the board the
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.
So I will need to get a different SFP module that is supported by the
kernel to finish testing. Hopefully kernel support is added in the
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Sunday, 16 June 2024 15:20:05 CEST Leith Bade wrote: > I need to work out how to submit these fixes to the Linux device tree > maintainers. My experience is primarily/only with Rockchip based devices/SoCs and their upstream development process, but it may help wrt MediaTek's. - If you think something is wrong, determine with ``git blame`` which commit added that (presumably) incorrect statement(s) - In the commit message, you'll often find a ``Link: `` line which points to the discussion of that change and should point to https://lore.kernel.org/ - If there isn't a ``Link: `` line, you can put the title of the commit in the 'lore' search box and search through all the archives; reasonable chance that'll point you to the discussion thread(s) - Read through the whole discussion as it may already provide answers to questions you may have - At the bottom of each 'lore' page, you'll find instructions on how to reply in case you have further questions/disagree/etc https://lists.infradead.org/mailman/listinfo/linux-mediatek is where patch discussion takes place (which gets 'archived' on lore.k.o). You may want to subscribe to that list to get an idea how the upstreaming process takes place. Keep in mind that the volume of that/those list(s) can be huge and that your email address will be publicly/wildly known (just like on Debian bug reports). https://git-send-email.io/ is probably worth a look and also the ``b4`` tool. HTH, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
This weekend I went over the current Linux BPI-R3 Device Tree file in the linux master branch in order to fix some issues I encountered with the Ubuntu 6.8 kernel. I compared everything to the BPI-R3 schematics as well as the MT7986 datasheet and these are the issues I found and fixed in my copy so far: - there was no memory block - not used by Linux but I think is used by U-boot - pcie - was missing the pice_wake pin group - though had to remove it again due to: - the two pin groups pcie_clk and pcie_wake conflict with GPIO pins used by the reset and WPS push buttons - the schematic is ambiguous as to how things are wired, it has both the buttons and M.2 connector using the same nets though with some optional 0 Ohm resistors (or jumpers) which makes it hard to know what is actually happening without multimeter probing - removing the two pin groups allows the pcie device to actually be loaded - I need to get a NVMe SSD to test it out - uart0 - missing the pin group - ethernet mdio-bus - used GPIO 5 pin for reset but, this is actually connected instead to a DIP switch for boot device selection - there was no audio device - the drivers only recently been added to kernel - I grabbed the definition from OpenWrt, though the MediaTek SDK though they disagrees on one of the clocks so I need to work out what is correct - there are header pins for connecting audio codec chip via CON1 but I only just ordered such a codec so can't test it properly yet - there was no SNFI device - I grabbed the definition from the MediaTek SDK - there is an empty solder pad for an SNFI chip so I don't think I will be able to test this unless I find someone who has installed such a chip to test - ssusb - missing required voltage regulator definitions I need to work out how to submit these fixes to the Linux device tree maintainers. Diederik has also given me a pre-built Debian kernel to test which I will do next.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Thursday, 13 June 2024 23:00:51 CEST Leith Bade wrote: > Excellent, hopefully we can get the DTS stuff from OpenWrt upstreamed into > Linux for the OpenWrt and BPI-R3. I have (thus far) found one possible oddity, but otherwise it looks ok AFAICT for BPI-R3. When that's done, the OpenWrt One should be rather simple. But only *IF* they upstream it in time. > I am not sure what the process is for that. The first step would be to get involved with the community. I'm quite sure there's one or more threads about the BPI-R3 on the OpenWrt forums. > As for the MT7988 I can save up and get a BPI-R4 for testing in the future, > though I have a feeling that the Debian testing kernel might be too old, > the drivers were only added to Linux 5 months ago. So maybe I will wait > until there is a Debian version with a newer kernel. I did look (briefly) into MT7988 and the problem isn't on the Debian side, but on the upstream side. Looking at the mt7988a.dtsi and it seems there's *quite* a lot missing. And the BPI-R4 dts file includes that incomplete dtsi file and then specifies the model name and chassis-type. That's it. If you compare that with BPI-R3 then you'll see a huge difference. So it looks like there's quite some work to do before the BPI-R4 is supported upstream, which is a prerequisite for support in Debian. I haven't looked (at Mailing Lists), but I would be very surprised if we could get (proper) support in the Trixie kernel. If you're interested in this kind of thing, you have enough time to learn and contribute to get proper support for it in the Forky kernel. HTH, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Thu, 13 Jun 2024 at 23:59, Bjørn Mork wrote: > Leith Bade writes: > > > Also, has a public version of the MT7981 Reference Manual been published? > > Google only finds me a pirated partial copy on Scribd. This will be > needed > > to get all the memory locations for the DTS file, otherwise we will need > to > > steal them from the DTS files in the Mediatek SDK or OpenWRT. > > Don't think the reference manual has been published. But I believe > you'll find the register locations you need in the docs Mediatek has > made available for the OpenWrt One: > https://mirror2.openwrt.org/docs/ > > Not sure it makes much sense duplicating the work already done by > OpenWrt though. > > > Bjørn > Excellent, hopefully we can get the DTS stuff from OpenWrt upstreamed into Linux for the OpenWrt and BPI-R3. I am not sure what the process is for that. As for the MT7988 I can save up and get a BPI-R4 for testing in the future, though I have a feeling that the Debian testing kernel might be too old, the drivers were only added to Linux 5 months ago. So maybe I will wait until there is a Debian version with a newer kernel.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
Leith Bade writes: > Also, has a public version of the MT7981 Reference Manual been published? > Google only finds me a pirated partial copy on Scribd. This will be needed > to get all the memory locations for the DTS file, otherwise we will need to > steal them from the DTS files in the Mediatek SDK or OpenWRT. Don't think the reference manual has been published. But I believe you'll find the register locations you need in the docs Mediatek has made available for the OpenWrt One: https://mirror2.openwrt.org/docs/ Not sure it makes much sense duplicating the work already done by OpenWrt though. Bjørn
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Thursday, 13 June 2024 13:55:40 CEST Diederik de Haas wrote: > > Banana Pi released a public version of the MT7986 manual which has all the > > various register memory locations documented, though some stuff is > > missing. > > Only after writing the previous line, I realized you were talking about the > MT798*1*, not the MT7986. And that means the OpenWrt One thread will be > 'gold' as they intend to be as Open as possible, so check the Popular Links > in the opening post. > That should also lead you to https://mirror2.openwrt.org/docs/ What I forgot to mention: MediaTek (employees) seem to contribute actively to the upstream Linux kernel. And they agreed to publish those detailed docs related to the OpenWrt One. Which indicates to me they have a very friendly attitude towards Linux and FLOSS. So if you want a doc but can't find it (online), maybe just write them an email and ask for it? I don't know if they respond (positively), but certainly seems worth a try? Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Wednesday, 12 June 2024 23:45:30 CEST Leith Bade wrote: > Also, has a public version of the MT7981 Reference Manual been published? I have no idea. I have not searched and actually don't know much/anything about MediaTek devices in general. All I'm using is what is described in the DTS file in the upstream Linux repo. > Google only finds me a pirated partial copy on Scribd. This will be needed > to get all the memory locations for the DTS file, otherwise we will need to > steal them from the DTS files in the Mediatek SDK or OpenWRT. It's probably a good idea to find out if there are differences in what OpenWrt has/uses and what's available in the upstream Linux repo. If there are, it would be great if those changes/improvements can be upstreamed (to the Linux kernel). Probably best to ask (and search) in the OpenWrt forums. There's a LOT of info there and quite a number of (very) knowledgeable people. They may also know about or have MT7981 TRM(s). > Banana Pi released a public version of the MT7986 manual which has all the > various register memory locations documented, though some stuff is missing. Only after writing the previous line, I realized you were talking about the MT798*1*, not the MT7986. And that means the OpenWrt One thread will be 'gold' as they intend to be as Open as possible, so check the Popular Links in the opening post. That should also lead you to https://mirror2.openwrt.org/docs/ Have fun ;-) signature.asc Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Wednesday, 12 June 2024 23:40:41 CEST Leith Bade wrote: > Ideally if in your new kernel build you enable support for MT7981, MT7986, > MT7988 at the same time that would be nice. I'll only add support for the MT7986 in my kernel build as that one can be tested (by you) to actually work as intended. Adding support for the other SoCs should then become much simpler as all the 'ground work' has already been done. But to add that to the Debian kernel, we'd need one with a device with that SoC so that it too can be tested to actually work. signature.asc Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
Also, has a public version of the MT7981 Reference Manual been published? Google only finds me a pirated partial copy on Scribd. This will be needed to get all the memory locations for the DTS file, otherwise we will need to steal them from the DTS files in the Mediatek SDK or OpenWRT. Banana Pi released a public version of the MT7986 manual which has all the various register memory locations documented, though some stuff is missing. Thanks, Leith Bade le...@bade.nz
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Wed, 12 Jun 2024 at 23:59, Diederik de Haas wrote: > On Tuesday, 11 June 2024 09:01:20 CEST Diederik de Haas wrote: > > I already have a local branch to add preliminary support for the OpenWrt > One > > router [1] [2] which uses the same SoC :-) > > I was wrong. > $ grep ".dtsi" arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts > #include "mt7986a.dtsi" > > $ grep ".dtsi" arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts > #include "mt7981b.dtsi" > > I'm not sure but it could be Filogic 830 vs Filogic 820 platform? I > wouldn't > be surprised if there are some shared things, but those are different SoCs. As far as I am aware they are very similar chips and most of the internals are shared. However the MT7981 (and MT7988) are newer chips and the MT7981 DTS file was only added 4 months ago to the kernel. A quick grep for "mediatek,mt7981" shows support has been added to the relevant drivers over the past year so I think this is mainly the case of writing a complete DTS file perhaps by basing it on the MT7986 file and updating memory addresses etc. If we can get a build running on the MT7986 hopefully it will also boot on MT7981. If we do find issues with MT7981 drivers then maybe you will need to test sid to get the most recent kernel changes. Ideally if in your new kernel build you enable support for MT7981, MT7986, MT7988 at the same time that would be nice.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Tuesday, 11 June 2024 09:01:20 CEST Diederik de Haas wrote: > I already have a local branch to add preliminary support for the OpenWrt One > router [1] [2] which uses the same SoC :-) I was wrong. $ grep ".dtsi" arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts #include "mt7986a.dtsi" $ grep ".dtsi" arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts #include "mt7981b.dtsi" I'm not sure but it could be Filogic 830 vs Filogic 820 platform? I wouldn't be surprised if there are some shared things, but those are different SoCs. signature.asc Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
On Tuesday, 11 June 2024 12:26:17 CEST Leith Bade wrote: > For the record the issues I noticed are (comparing with U-boot and OpenWRTs > versions of the device tree files): > - mt7986a.dtsi is missing entry for the SNFI / SNAND interface to load > https://github.com/torvalds/linux/blob/83a7eefedc9b56fe7bfeff13b6c7356688ffa > 670/drivers/spi/spi-mtk-snfi.c this is not populated on the BPI-R3 but other > boards might use this Generally, `*.dtsi` files get included into other files, usually `.dts` files. The `mt7986a.dtsi` (likely) describes the SoC, not the full device. The device likely has the flash chip, not the SoC, so the dts file should have an entry for the flash chip (the dts file for OpenWrt One does f.e.). > - in OpenWRT device tree there are a lot more entries in the efuse map > related to the USB and PCIe ports - it seems the USB and PCIe device entries > then use these efuse values DeviceTree files describe the hardware, so *ideally* there should be no difference between what the Linux kernel has (which is generally considered the upstream project for DT files) and what OpenWrt has/uses. Unfortunately, we don't live in an ideal world ;-) If OpenWrt's DT are better (I don't know), then it would be great if they would upstream their improvements to the Linux kernel. But AFAIK, OpenWrt has/manages their own kernel and DT files. I know u-boot now has an OF_UPSTREAM (OF=OpenFirmware=DT) 'setting', which I *think* means they're (in the process of) switching to using the Linux kernel's DeviceTree files. > - no hnat device - though maybe this is only usable with the proprietary > Mediatek driver code I have no idea what that is (for). > - in OpenWRT device tree there is a different "compatible" string for spi0 > (quad) and spi1 (single) - I am not sure if that matters with the upstream > driver, hopefully there is a way to check that the MTD device is using the > quad SPI / SPIM mode The "compatible" string is used to find the appropriate driver (IIUC), so if spi0 and spi1 have different "compatible"s, then they (apparently) need different drivers from them. But as said before, (technically) OpenWrt is their own project, so it doesn't have to match what current upstream does/has. (OpenWrt doesn't track Linus' 'master' branch but the most recent LTS version, which they then patch) > - the BPI-R3 .dtso overlay files for the NAND and NOR flash options have > partition definitions that don't match the device tree in U-boot and > OpenWRT - ideally these should match the partitions on a factory fresh > board which comes OpenWRT preloaded It (generally) doesn't sound good if different projects use/assume different partition layouts. It could be one (or more) projects have incorrect and/or incomplete implementation. I don't know. It could be worth investigating what the correct values are and submitting patches to those projects to get that fixed. > I noticed a few problems but I am not sure what normal protocol is - should > I report it as a bug to Linux directly? The best way to deal with it depends on the project (and could also depend on the subsystem of that project). AFAIK they all use Mailing Lists, but AFAIK OpenWrt also use Pull Requests on GH, which the (majority of the) Linux kernel does not. So you'll need to investigate how the project(s) you want to contribute too (generally) operates. And learn/verify whether what you found is actually a bug and in which project(s) the problem is, and not f.e. that you were looking in the wrong place (dtsi vs dts). HTH and have fun! Diederik PS: this bug report is probably not the right place for these kind of discussions signature.asc Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
What should I do with issues related to the Linux upstream device tree files? I noticed a few problems but I am not sure what normal protocol is - should I report it as a bug to Linux directly? For the record the issues I noticed are (comparing with U-boot and OpenWRTs versions of the device tree files): - mt7986a.dtsi is missing entry for the SNFI / SNAND interface to load https://github.com/torvalds/linux/blob/83a7eefedc9b56fe7bfeff13b6c7356688ffa670/drivers/spi/spi-mtk-snfi.c this is not populated on the BPI-R3 but other boards might use this - in OpenWRT device tree there are a lot more entries in the efuse map related to the USB and PCIe ports - it seems the USB and PCIe device entries then use these efuse values - no hnat device - though maybe this is only usable with the proprietary Mediatek driver code - in OpenWRT device tree there is a different "compatible" string for spi0 (quad) and spi1 (single) - I am not sure if that matters with the upstream driver, hopefully there is a way to check that the MTD device is using the quad SPI / SPIM mode - the BPI-R3 .dtso overlay files for the NAND and NOR flash options have partition definitions that don't match the device tree in U-boot and OpenWRT - ideally these should match the partitions on a factory fresh board which comes OpenWRT preloaded Additionally I managed to get Ubuntu 24.04 installed for testing and I will recompile the kernel to add Ethernet device support. This will provide me with a useful reference to test against a Debian install to make sure all devices are showing up. Thanks, Leith Bade le...@bade.nz On Tue, 11 Jun 2024 at 17:01, Diederik de Haas wrote: > Hi, > > On Tuesday, 11 June 2024 08:02:41 CEST Leith Bade wrote: > > I have a Bananapi BPI-R3 board which uses the Mediatek MT7986 ARM64 SoC > for > > its CPU. This is a router focussed board and currently has good support > in > > the OpenWRT distribution and in the upstream Linux for a few years. The > > device tree for this board is > > > https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/mediatek/m > > t7986a-bananapi- bpi-r3.dts (as well as some .dtso files to enable > specific > > flash chip options). > > I already have a local branch to add preliminary support for the OpenWrt > One > router [1] [2] which uses the same SoC :-) > > [1] > https://forum.openwrt.org/t/openwrt-one-celebrating-20-years-of-openwrt/183684 > [2] > https://forum.openwrt.org/t/openwrt-one-celebrating-20-years-of-openwrt/183684/331 > > > There is a relevant discussion in https://salsa.debian.org/kernel- > > team/linux/-/merge_requests/906#note_483427 which was the code change > that > > added the MT8xxx support about the various MT6xxx and MT7xxx modules > being > > disabled. This is a shame as it seems that without explicitly disabling > them > > then this code change would have added the modules I need. > > > > I am happy to do any testing required to get this board supported. > > And that was precisely about adding support for the OpenWrt One ;-) > > Happy to update my local branch and add support for the BPi R-3. > I'm waiting for some (unrelated) other changes, but when that's posted > I intend to build a 6.10-rcX based kernel with it and I can 'merge' my > router branch into that. With that you could verify if it indeed works. > > HTH, > Diederik
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
Hi Diederik, Thanks for the update - I noticed you have popped up in a few places related to the Mediatek SoCs. That's great to hear things are progressing on the Debian kernel front. Thanks, Leith Bade le...@bade.nz
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
Hi, On Tuesday, 11 June 2024 08:02:41 CEST Leith Bade wrote: > I have a Bananapi BPI-R3 board which uses the Mediatek MT7986 ARM64 SoC for > its CPU. This is a router focussed board and currently has good support in > the OpenWRT distribution and in the upstream Linux for a few years. The > device tree for this board is > https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/mediatek/m > t7986a-bananapi- bpi-r3.dts (as well as some .dtso files to enable specific > flash chip options). I already have a local branch to add preliminary support for the OpenWrt One router [1] [2] which uses the same SoC :-) [1] https://forum.openwrt.org/t/openwrt-one-celebrating-20-years-of-openwrt/183684 [2] https://forum.openwrt.org/t/openwrt-one-celebrating-20-years-of-openwrt/183684/331 > There is a relevant discussion in https://salsa.debian.org/kernel- > team/linux/-/merge_requests/906#note_483427 which was the code change that > added the MT8xxx support about the various MT6xxx and MT7xxx modules being > disabled. This is a shame as it seems that without explicitly disabling them > then this code change would have added the modules I need. > > I am happy to do any testing required to get this board supported. And that was precisely about adding support for the OpenWrt One ;-) Happy to update my local branch and add support for the BPi R-3. I'm waiting for some (unrelated) other changes, but when that's posted I intend to build a 6.10-rcX based kernel with it and I can 'merge' my router branch into that. With that you could verify if it indeed works. HTH, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
Package: linux-image-6.7.12-arm64 Version: 6.7.12-1 Severity: important Tags: newcomer Dear Maintainer, I have a Bananapi BPI-R3 board which uses the Mediatek MT7986 ARM64 SoC for its CPU. This is a router focussed board and currently has good support in the OpenWRT distribution and in the upstream Linux for a few years. The device tree for this board is https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/mediatek/mt7986a-bananapi- bpi-r3.dts (as well as some .dtso files to enable specific flash chip options). I have managed to get a custom U-boot build running that supports UEFI. So I started testing the Ubuntu and Debian installers on a USB stick. With Ubuntu 22.04 (HWE kernel) and 24.04 the USB stick boots up into the installer fine, however the Ethernet drivers are missing. For Debian I tried the Debian stable 12.5.0 DVD ISO and the latest Debian testing DVD ISO. Both boot into the GRUB menu fine, but after editing the GRUB command line to remove the "quiet" kernel option, the Kernel fails to boot and is left with no output except for the U-boot UEFI messages: EFI stub: Booting Linux Kernel... EFI stub: EFI_RNG_PROTOCOL unavailable EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path EFI stub: Using DTB from configuration table EFI stub: Exiting boot services... There is a similar bug report #1052676 which was about supporting some MT8xxx based Chromebooks. So I had a look at the kernel modules included in the current testing kernel: https://packages.debian.org/trixie/arm64/linux-image-6.7.12-arm64/filelist I can see the various MT8xxx module files, but no files for the MT7986. I believe based on my Ubuntu results that if all the modules required are built, then Debian testing will be able to boot on this board. There is a relevant discussion in https://salsa.debian.org/kernel- team/linux/-/merge_requests/906#note_483427 which was the code change that added the MT8xxx support about the various MT6xxx and MT7xxx modules being disabled. This is a shame as it seems that without explicitly disabling them then this code change would have added the modules I need. I am happy to do any testing required to get this board supported. I think it would also be useful to enable support for the MT7988 SoC and Bananapi have a new board, the BPI-R4 with this chip. I have not yet purchased this board, but I can do for testing with that SoC as well. On the U-boot side, there is another related bug report #1037281. Once I can get the kernel booting, I am happy to help with U-boot as well, based on my findings so far. -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), (100, 'focal-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-107-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_LIVEPATCH Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
