Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #82697 > unrolled thread

Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Leith Bade <leith@bade.nz> - 2024-06-11 08:10 +0200
    Bug#1072968: Acknowledgement (linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC) Leith Bade <leith@bade.nz> - 2024-06-11 08:20 +0200
    Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Diederik de Haas <didi.debian@cknow.org> - 2024-06-11 09:20 +0200
      Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Leith Bade <leith@bade.nz> - 2024-06-11 12:20 +0200
      Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Leith Bade <leith@bade.nz> - 2024-06-11 12:40 +0200
        Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Diederik de Haas <didi.debian@cknow.org> - 2024-06-11 14:20 +0200
      Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Diederik de Haas <didi.debian@cknow.org> - 2024-06-12 16:20 +0200
        Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Leith Bade <leith@bade.nz> - 2024-06-12 23:50 +0200
          Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Diederik de Haas <didi.debian@cknow.org> - 2024-06-13 14:00 +0200
            Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Diederik de Haas <didi.debian@cknow.org> - 2024-06-13 14:10 +0200
        Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Leith Bade <leith@bade.nz> - 2024-06-12 23:50 +0200
          Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Diederik de Haas <didi.debian@cknow.org> - 2024-06-13 13:50 +0200
        Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Diederik de Haas <didi.debian@cknow.org> - 2024-07-11 15:30 +0200
    Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Bjørn Mork <bjorn@mork.no> - 2024-06-13 16:20 +0200
      Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Leith Bade <leith@bade.nz> - 2024-06-13 23:10 +0200
        Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Diederik de Haas <didi.debian@cknow.org> - 2024-06-13 23:30 +0200
        Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Leith Bade <leith@bade.nz> - 2024-06-16 15:30 +0200
          Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Diederik de Haas <didi.debian@cknow.org> - 2024-06-16 15:50 +0200
          Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Leith Bade <leith@bade.nz> - 2024-06-24 07:20 +0200
            Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Diederik de Haas <didi.debian@cknow.org> - 2024-06-24 13:00 +0200
              Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Leith Bade <leith@bade.nz> - 2024-06-24 15:20 +0200
    Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Leith Bade <leith@bade.nz> - 2024-06-24 15:00 +0200
      Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Diederik de Haas <didi.debian@cknow.org> - 2024-06-24 15:10 +0200
    Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Diederik de Haas <didi.debian@cknow.org> - 2024-06-24 15:20 +0200
      Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Leith Bade <leith@bade.nz> - 2024-06-26 00:30 +0200
      Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Leith Bade <leith@bade.nz> - 2024-06-26 03:10 +0200
        Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Diederik de Haas <didi.debian@cknow.org> - 2024-06-28 09:00 +0200
          Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Leith Bade <leith@bade.nz> - 2024-06-30 13:10 +0200
          Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Diederik de Haas <didi.debian@cknow.org> - 2024-07-19 19:00 +0200
            Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC Leith Bade <leith@bade.nz> - 2024-07-20 01:00 +0200
    Processed: Re: Bug#1072968: linux-image-6.7.12-arm64: Add support  for Mediatek MT7986 SoC "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-06-28 09:00 +0200
    Processed: Re: Bug#1072968: linux-image-6.7.12-arm64: Add support  for Mediatek MT7986 SoC "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-07-19 19:00 +0200
    Bug#1072968: marked as done (linux-image-6.7.12-arm64: Add  support for Mediatek MT7986 SoC) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-07-27 10:10 +0200

Page 1 of 2  [1] 2  Next page →

#82697 — 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

[toc] | [next] | [standalone]

#82698 — Bug#1072968: Acknowledgement (linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC)

[Multipart message — attachments visible in raw view] — view raw

Please ignore the reportbug cruft attached to the previous email, I had to
run the reportbug tool on my Ubuntu laptop as the board isn't booting. Thus
reportbug seems to have picked up the Ubuntu environment.

[toc] | [prev] | [next] | [standalone]

#82701

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#82702

[Multipart message — attachments visible in raw view] — view raw

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
leith@bade.nz

[toc] | [prev] | [next] | [standalone]

#82703

[Multipart message — attachments visible in raw view] — view raw

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
leith@bade.nz


On Tue, 11 Jun 2024 at 17:01, Diederik de Haas <didi.debian@cknow.org>
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

[toc] | [prev] | [next] | [standalone]

#82704

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#82708

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#82713

[Multipart message — attachments visible in raw view] — view raw

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
leith@bade.nz

[toc] | [prev] | [next] | [standalone]

#82717

[Multipart message — attachments visible in raw view] — view raw

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 ;-)

[toc] | [prev] | [next] | [standalone]

#82718

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#82714

[Multipart message — attachments visible in raw view] — view raw

On Wed, 12 Jun 2024 at 23:59, Diederik de Haas <didi.debian@cknow.org>
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.

[toc] | [prev] | [next] | [standalone]

#82716

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#82963

[Multipart message — attachments visible in raw view] — view raw

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-zajec5@gmail.com/
https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux.git/tag/?h=mtk-dts64-for-v6.11

[toc] | [prev] | [next] | [standalone]

#82719

Leith Bade <leith@bade.nz> 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

[toc] | [prev] | [next] | [standalone]

#82721

[Multipart message — attachments visible in raw view] — view raw

On Thu, 13 Jun 2024 at 23:59, Bjørn Mork <bjorn@mork.no> wrote:

> Leith Bade <leith@bade.nz> 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.

[toc] | [prev] | [next] | [standalone]

#82722

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#82730

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#82731

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#82813

[Multipart message — attachments visible in raw view] — view raw

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-kernel@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@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"
"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 future
for these generic "OEM" modules.

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:
> [   12.223999] mt798x-wmac 18000000.wifi: HW/SW Version: 0x8a108a10,
Build Time: 20221012174743a
> [   12.421392] mt798x-wmac 18000000.wifi: WM Firmware Version:
____000000, Build Time: 20221012174805
> [   12.502713] mt798x-wmac 18000000.wifi: WA Firmware Version:
DEV_000000, Build Time: 20221012174937
> [   13.353937] mt7530-mdio mdio-bus:1f eth2: Link is Up - 1Gbps/Full -
flow control rx/tx
> [   33.762672] mt798x-wmac 18000000.wifi: Message 00000002 (seq 9) timeout
> [   33.769356] mt798x-wmac 18000000.wifi: Failed to start WA firmware
> [   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
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
> W: Possible missing firmware /lib/firmware/mediatek/mt7988_wo_0.bin for
module mtk_eth
> W: Possible missing firmware /lib/firmware/mediatek/mt7986_wo_1.bin for
module mtk_eth
> W: Possible missing firmware /lib/firmware/mediatek/mt7986_wo_0.bin for
module mtk_eth
> W: Possible missing firmware /lib/firmware/mediatek/mt7981_wo.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.
So I cloned the upstream "linux-firmware" git repository, ran "make deb" to
generate a "linux-firmware-upstream_20240610-26-gcea56a5d_all.deb" file.
After installing this deb package the required firmware files were
installed in /lib/firmware/updates.
However I kept getting the error. I ended up searching in Google and found
some notes in OpenWrt bug tickets and on Banana Pi forum that certain
USB-to-serial devices plugged into the UART0 header on the board can cause
this problem. The reason is that one of the UART0 pins is used as a
bootstrap pin for the SoC to configure the WiFi chips, and if the serial
device is pulling the pin the wrong way the WiFi chip will be configured
incorrectly at power on. I needed UART0 to get though U-boot so I tried a
different FTDI USB cable I have that is reported to work with the WiFi.
After powering off/on the board with the FTDI cable plugged in the WiFi
started working.
The driver now loads in the boot log:
[   13.464015] mt798x-wmac 18000000.wifi: HW/SW Version: 0x8a108a10, Build
Time: 20221012174743a
[   13.630128] mt798x-wmac 18000000.wifi: WM Firmware Version: ____000000,
Build Time: 20221012174805
[   13.698079] mt798x-wmac 18000000.wifi: WA Firmware Version: DEV_000000,
Build Time: 20221012174937
[   13.840792] mt798x-wmac 18000000.wifi: eeprom load fail, use default bin
[   13.845097] mt798x-wmac 18000000.wifi: registering led 'mt76-phy0'
[   13.851770] mt798x-wmac 18000000.wifi: registering led 'mt76-phy1'

There is a wlan0/wlan1 device created and iwconfig finds them. I did not
try connecting to a WiFi network as I don't have the antenna cables yet to
plug into the board.

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
- need to update the Debian "firmware-misc-nonfree" to add the missing
MT79xx firmware files
- 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
- don't plug in a non-FTDI chip based USB-to-serial cable into the UART0
port otherwise WiFi will not work

[toc] | [prev] | [next] | [standalone]

#82815

[Multipart message — attachments visible in raw view] — view raw

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-kernel@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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.kernel

csiph-web