Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1052676: linux-config: Enabling Kernel Configurations for MediaTek Platforms (CONFIG_ARCH_MEDIATEK) (config-linux-6.5)
15 views
Skip to first unread message
Macpaul Lin
Sep 25, 2023, 10:10:04 PM9/25/23
to
Package: linux-config-6.5
Version: 6.5.3-1
Severity: normal
Release: bookworm, trixie
Dear Maintainers,
[RESEND] Sorry for bothering because the format of bug report was
incorrect in previous mail.
I am currently working on enabling Debian on MediaTek platforms. The
target SoCs include MT8365, MT8195/MT8395, and MT8188/MT8390. I
attempted to use a USB flash drive with the latest Debian release DVD
image on these boards, but there were no logs available after jumping
into the kernel from grub.
Upon examining the kernel configurations, I noticed that none of the
MediaTek-related kernel configurations are enabled by default. As a
result, I plan to submit patches and file issues with the Debian
community. I think the very beginning configration will be
"CONFIG_ARCH_MEDIATEK=y" and other necessary peripherals like
power/clock/uart, etc.
Although I have experience as a Debian user, I am new to the role of an
issue reporter. I have read the bug report how-to guide, but I still
have some questions about submitting patches for SoC enablement on
Debian. This is particularly challenging as this is the first time to
port MediaTek platforms to the Debian distribution. I have registered
for the kernel mailing list and created a GitLab account for sending
merge requests.
Here are my questions:
1. What is the best way to file issues with patches? Should I file one
issue per patch or per single configuration change?
2. Should I send a series of patches for platform enablement as a single
issue via GitLab, or should I send patches through the mailing list (bug
report system)?
3. Should I submit bugs for enabling kernel configurations to multiple
kernel versions? (6.1, 6.4, 6.5) This might cause same issues for
different kernel versions show up in bug tracking system.
4. Should I send patches for different branches separately? For
instance, I have cloned
"https://salsa.debian.org/kernel-team/linux.git". Should I send patches
or merge requests for different branches like bookworm and trixie to
keep the setting in future releases?
5. Is there a verification method for kernel configurations on Debian? I
currently have a running Ubuntu on MediaTek platforms and can debug
kernel configurations on Ubuntu. However, I don't have a bootable Debian
on these boards. Should I use debootstrap
"https://wiki.debian.org/Debootstrap" on Ubuntu boards to install Debian
and build the Debian kernel at the initial stage?
I appreciate your guidance on these matters. I am eager to contribute to
kernel configurations on Debian for MediaTek platforms.
Best regards,
Macpaul Lin
Version: 6.5.3-1
Severity: normal
Release: bookworm, trixie
Dear Maintainers,
[RESEND] Sorry for bothering because the format of bug report was
incorrect in previous mail.
I am currently working on enabling Debian on MediaTek platforms. The
target SoCs include MT8365, MT8195/MT8395, and MT8188/MT8390. I
attempted to use a USB flash drive with the latest Debian release DVD
image on these boards, but there were no logs available after jumping
into the kernel from grub.
Upon examining the kernel configurations, I noticed that none of the
MediaTek-related kernel configurations are enabled by default. As a
result, I plan to submit patches and file issues with the Debian
community. I think the very beginning configration will be
"CONFIG_ARCH_MEDIATEK=y" and other necessary peripherals like
power/clock/uart, etc.
Although I have experience as a Debian user, I am new to the role of an
issue reporter. I have read the bug report how-to guide, but I still
have some questions about submitting patches for SoC enablement on
Debian. This is particularly challenging as this is the first time to
port MediaTek platforms to the Debian distribution. I have registered
for the kernel mailing list and created a GitLab account for sending
merge requests.
Here are my questions:
1. What is the best way to file issues with patches? Should I file one
issue per patch or per single configuration change?
2. Should I send a series of patches for platform enablement as a single
issue via GitLab, or should I send patches through the mailing list (bug
report system)?
3. Should I submit bugs for enabling kernel configurations to multiple
kernel versions? (6.1, 6.4, 6.5) This might cause same issues for
different kernel versions show up in bug tracking system.
4. Should I send patches for different branches separately? For
instance, I have cloned
"https://salsa.debian.org/kernel-team/linux.git". Should I send patches
or merge requests for different branches like bookworm and trixie to
keep the setting in future releases?
5. Is there a verification method for kernel configurations on Debian? I
currently have a running Ubuntu on MediaTek platforms and can debug
kernel configurations on Ubuntu. However, I don't have a bootable Debian
on these boards. Should I use debootstrap
"https://wiki.debian.org/Debootstrap" on Ubuntu boards to install Debian
and build the Debian kernel at the initial stage?
I appreciate your guidance on these matters. I am eager to contribute to
kernel configurations on Debian for MediaTek platforms.
Best regards,
Macpaul Lin
Debian Bug Tracking System
Sep 26, 2023, 4:50:04 PM9/26/23
to
Processing control commands:
> reassign -1 src:linux 6.5.3-1
Bug #1052676 [src:linux] linux-config: Enabling Kernel Configurations for MediaTek Platforms (CONFIG_ARCH_MEDIATEK) (config-linux-6.5)
Ignoring request to reassign bug #1052676 to the same package
Bug #1052676 [src:linux] linux-config: Enabling Kernel Configurations for MediaTek Platforms (CONFIG_ARCH_MEDIATEK) (config-linux-6.5)
Marked as found in versions linux/6.5.3-1.
> severity -1 wishlist
Bug #1052676 [src:linux] linux-config: Enabling Kernel Configurations for MediaTek Platforms (CONFIG_ARCH_MEDIATEK) (config-linux-6.5)
Severity set to 'wishlist' from 'normal'
--
1052676: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052676
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
> reassign -1 src:linux 6.5.3-1
Bug #1052676 [src:linux] linux-config: Enabling Kernel Configurations for MediaTek Platforms (CONFIG_ARCH_MEDIATEK) (config-linux-6.5)
Ignoring request to reassign bug #1052676 to the same package
Bug #1052676 [src:linux] linux-config: Enabling Kernel Configurations for MediaTek Platforms (CONFIG_ARCH_MEDIATEK) (config-linux-6.5)
Marked as found in versions linux/6.5.3-1.
> severity -1 wishlist
Bug #1052676 [src:linux] linux-config: Enabling Kernel Configurations for MediaTek Platforms (CONFIG_ARCH_MEDIATEK) (config-linux-6.5)
Severity set to 'wishlist' from 'normal'
--
1052676: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052676
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Diederik de Haas
Sep 26, 2023, 4:50:05 PM9/26/23
to
Control: reassign -1 src:linux 6.5.3-1
Control: severity -1 wishlist
On Tuesday, 26 September 2023 04:06:15 CEST Macpaul Lin wrote:
> I am currently working on enabling Debian on MediaTek platforms. The
> target SoCs include MT8365, MT8195/MT8395, and MT8188/MT8390.
>
The former would be needed for sending MRs; the latter is irrelevant.
> Here are my questions:
>
> 1. What is the best way to file issues with patches? Should I file one
> issue per patch or per single configuration change?
It's a bit arbitrary. We _could_ do it all in this bug report, but it's
probably more useful to file a bug report per platform for which you want to
add support. This is assuming that they can be handled separately.
> 2. Should I send a series of patches for platform enablement as a single
> issue via GitLab, or should I send patches through the mailing list (bug
> report system)?
You could (and probably should) list the needed kernel modules per platform
when you file a bug for support for that platform.
I'd recommend to then file a MR in which you add support for a particular
platform and with that you'd close the bug report you filed for that.
IOW: Do a 1-on-1 mapping between bug report and MR.
> 3. Should I submit bugs for enabling kernel configurations to multiple
> kernel versions? (6.1, 6.4, 6.5) This might cause same issues for
> different kernel versions show up in bug tracking system.
I don't know *IF* it's possible to still add hardware support to the 6.1
kernel which is used in Stable/Bookworm. Assuming the platforms were properly
supported in the upstream 6.1 kernel, then there still has been zero testing
with it on a Debian system, which does not sound ideal for Stable.
One of the Debian kernel maintainers would have to answer whether it is
possible at all for 6.1/Stable/Bookworm.
It is not a problem for Unstable, which if all goes well would mean it'll end
up in Testing/Trixie and I'd recommend to file it against version 6.5.3-1, just
like this bug.
> 4. Should I send patches for different branches separately? For
> instance, I have cloned
> "https://salsa.debian.org/kernel-team/linux.git". Should I send patches
> or merge requests for different branches like bookworm and trixie to
> keep the setting in future releases?
Until a Debian kernel maintainer has given the green light for inclusion in
Stable/Bookworm, I'd leave that aside for the time being.
You could target your MR to either the 'sid' or the 'master' branch; I usually
target the 'master' branch.
> 5. Is there a verification method for kernel configurations on Debian?
Sort of. When you submit a MR you are expected to have verified that it
actually works, which means you need to build a kernel with the changes of
your MR included and tested that on real hardware.
The Salsa CI pipeline also does some verifications, but that alone is not
sufficient before sending the MR. You need to build and test an actual kernel.
> I currently have a running Ubuntu on MediaTek platforms and can debug
> kernel configurations on Ubuntu.
I'm not sure what you mean by 'debugging' kernel configuration.
Can you explain what you mean by that?
> However, I don't have a bootable Debian on these boards. Should I use
> debootstrap "https://wiki.debian.org/Debootstrap" on Ubuntu boards to
> install Debian and build the Debian kernel at the initial stage?
I _think_, and you probably should, build and test it on a (pure) Debian
system. If you have *a*(nother) arm64 board which runs Debian, that would work
too. Otherwise, debootstrap is indeed an excellent tool to create an initial
Debian system (and AFAIK the host system/OS is not important).
I don't know if you could combine running `debootstrap` with building the
kernel and I'm inclined to think that's probably not a good idea (other then
'academic/enthusiastic' curiosity).
I'd go for:
1) Make a Debian system for an arm64 device
2) Boot into that and install all the needed packages for building a kernel
3) Build the kernel
4) Debootstrap a system for your target platform with a suitable bootloader
and install the kernel debs resulting from 3) onto that
5) Verify your Debian kernel work on that target platform
> I appreciate your guidance on these matters. I am eager to contribute to
> kernel configurations on Debian for MediaTek platforms.
HTH,
Diederik
PS: I removed the debian-arm/debian-kernel ML as this is a kernel matter and
this bug report already ensures it ends up on the debian-kernel ML.
I've kept the DDs as I don't know if they requested to be CC-ed explicitly.
Control: severity -1 wishlist
On Tuesday, 26 September 2023 04:06:15 CEST Macpaul Lin wrote:
> I am currently working on enabling Debian on MediaTek platforms. The
> target SoCs include MT8365, MT8195/MT8395, and MT8188/MT8390.
>
> Upon examining the kernel configurations, I noticed that none of the
> MediaTek-related kernel configurations are enabled by default. As a
> result, I plan to submit patches and file issues with the Debian
> community. I think the very beginning configration will be
> "CONFIG_ARCH_MEDIATEK=y" and other necessary peripherals like
> power/clock/uart, etc.
>
> MediaTek-related kernel configurations are enabled by default. As a
> result, I plan to submit patches and file issues with the Debian
> community. I think the very beginning configration will be
> "CONFIG_ARCH_MEDIATEK=y" and other necessary peripherals like
> power/clock/uart, etc.
>
> I still have some questions about submitting patches for SoC enablement on
> Debian. I have registered for the kernel mailing list and created a GitLab
> account for sending merge requests.
Did you create an account on Salsa, Debian's GitLab instance or on gitlab.com?
The former would be needed for sending MRs; the latter is irrelevant.
> Here are my questions:
>
> 1. What is the best way to file issues with patches? Should I file one
> issue per patch or per single configuration change?
probably more useful to file a bug report per platform for which you want to
add support. This is assuming that they can be handled separately.
> 2. Should I send a series of patches for platform enablement as a single
> issue via GitLab, or should I send patches through the mailing list (bug
> report system)?
when you file a bug for support for that platform.
I'd recommend to then file a MR in which you add support for a particular
platform and with that you'd close the bug report you filed for that.
IOW: Do a 1-on-1 mapping between bug report and MR.
> 3. Should I submit bugs for enabling kernel configurations to multiple
> kernel versions? (6.1, 6.4, 6.5) This might cause same issues for
> different kernel versions show up in bug tracking system.
kernel which is used in Stable/Bookworm. Assuming the platforms were properly
supported in the upstream 6.1 kernel, then there still has been zero testing
with it on a Debian system, which does not sound ideal for Stable.
One of the Debian kernel maintainers would have to answer whether it is
possible at all for 6.1/Stable/Bookworm.
It is not a problem for Unstable, which if all goes well would mean it'll end
up in Testing/Trixie and I'd recommend to file it against version 6.5.3-1, just
like this bug.
> 4. Should I send patches for different branches separately? For
> instance, I have cloned
> "https://salsa.debian.org/kernel-team/linux.git". Should I send patches
> or merge requests for different branches like bookworm and trixie to
> keep the setting in future releases?
Stable/Bookworm, I'd leave that aside for the time being.
You could target your MR to either the 'sid' or the 'master' branch; I usually
target the 'master' branch.
> 5. Is there a verification method for kernel configurations on Debian?
actually works, which means you need to build a kernel with the changes of
your MR included and tested that on real hardware.
The Salsa CI pipeline also does some verifications, but that alone is not
sufficient before sending the MR. You need to build and test an actual kernel.
> I currently have a running Ubuntu on MediaTek platforms and can debug
> kernel configurations on Ubuntu.
Can you explain what you mean by that?
> However, I don't have a bootable Debian on these boards. Should I use
> debootstrap "https://wiki.debian.org/Debootstrap" on Ubuntu boards to
> install Debian and build the Debian kernel at the initial stage?
system. If you have *a*(nother) arm64 board which runs Debian, that would work
too. Otherwise, debootstrap is indeed an excellent tool to create an initial
Debian system (and AFAIK the host system/OS is not important).
I don't know if you could combine running `debootstrap` with building the
kernel and I'm inclined to think that's probably not a good idea (other then
'academic/enthusiastic' curiosity).
I'd go for:
1) Make a Debian system for an arm64 device
2) Boot into that and install all the needed packages for building a kernel
3) Build the kernel
4) Debootstrap a system for your target platform with a suitable bootloader
and install the kernel debs resulting from 3) onto that
5) Verify your Debian kernel work on that target platform
> I appreciate your guidance on these matters. I am eager to contribute to
> kernel configurations on Debian for MediaTek platforms.
Diederik
PS: I removed the debian-arm/debian-kernel ML as this is a kernel matter and
this bug report already ensures it ends up on the debian-kernel ML.
I've kept the DDs as I don't know if they requested to be CC-ed explicitly.
Debian Bug Tracking System
Oct 4, 2023, 7:30:04 PM10/4/23
to
Processing control commands:
> severity -1 important
> severity -1 important
Bug #1052676 [src:linux] linux-config: Enabling Kernel Configurations for MediaTek Platforms (CONFIG_ARCH_MEDIATEK) (config-linux-6.5)
Severity set to 'important' from 'wishlist'
0 new messages