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 2 of 2 — ← Prev page 1 [2]

#82823

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

On Mon, 24 Jun 2024 at 20:32, Diederik de Haas <didi.debian@cknow.org>
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-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 ...
>

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 <your@email.address>" 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 available in my next build
>

OK, I will give that a test.


> I'm still missing a "Tested-by:" tag for my changes ;-P
>

Tested-by: Leith Bade <leith@bade.nz>

Thanks,
Leith

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

#82820

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

On Mon, 24 Jun 2024 at 22:10, Leith Bade <leith@bade.nz> 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?

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

#82821

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

On Monday, 24 June 2024 14:43:38 CEST Leith Bade wrote:
> On Mon, 24 Jun 2024 at 22:10, Leith Bade <leith@bade.nz> 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 <filename|path>``
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)

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

#82822

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

On Monday, 24 June 2024 14:10:18 CEST Leith Bade wrote:
> On 24 Jun 2024 at 20:32, Diederik de Haas <didi.debian@cknow.org> 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 <leith@bade.nz>

Haha, thanks :)

Cheers,
  Diederik

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

#82838

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

Thanks,
Leith Bade
leith@bade.nz


On Mon, 24 Jun 2024 at 23:10, Diederik de Haas <didi.debian@cknow.org>
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@10320000:
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@10320000:
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.

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

#82839

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

Diederik provided me with a new v6.10 kernel build to try:
[    0.000000] Linux version 6.10-rc5+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~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.

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

#82868

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

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.000000] Linux version 6.10-rc5+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~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

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

#82884

> 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

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

#83113

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

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/

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

#83125

That is great news, I will install it once it has been uploaded.

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

#82869 — Processed: Re: Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC

Processing control commands:

> tag -1 patch
Bug #1072968 [src:linux] linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
Added tag(s) patch.

-- 
1072968: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072968
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

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

#83114 — Processed: Re: Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC

Processing control commands:

> tag -1 pending
Bug #1072968 [src:linux] linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
Added tag(s) pending.

-- 
1072968: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072968
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

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

#83238 — Bug#1072968: marked as done (linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC)

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

Your message dated Sat, 27 Jul 2024 08:02:27 +0000
with message-id <E1sXcNn-008RHY-Ee@fasolo.debian.org>
and subject line Bug#1072968: fixed in linux 6.10.1-1~exp1
has caused the Debian Bug report #1072968,
regarding linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1072968: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072968
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web