On Mon, 24 Jun 2024 at 20:32, Diederik de Haas <didi.deb...@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 <le...@bade.nz>
Thanks,
Leith
