ath9k: support for Extreme Networks AP3805i

[Sergey Ryazanov]

Hello Eugenio,

On Sat, Feb 26, 2022 at 1:22 PM Eugenio Tampieri via openwrt-devel
<openwrt-devel at lists.openwrt.org> wrote:
> The sender domain has a DMARC Reject/Quarantine policy which disallows
> sending mailing list messages using the original "From" header.
>
> To mitigate this problem, the original message has been wrapped
> automatically by the mailing list software.

Please consider configuring the DMARC DNS record properly for mailing
lists usage, it is quite annoying to reply to a message that was
wrapped to another message by the mailing list software. BTW, use the
bottom-posting (https://en.wikipedia.org/wiki/Posting_style), please.

All this is boring, let's talk about something more interesting.

> ---------- Forwarded message ----------
> From: Eugenio Tampieri <eugenio at eutampieri.eu>
> To: openwrt-devel at lists.openwrt.org
> Date: Sat, 26 Feb 2022 11:08:56 +0100
> Subject: ath9k: support for Extreme Networks AP3805i
> Sorry for resubmitting this but yesterday I submitted without a subject...
> I'm a CS student and I've used OpenWrt for years. I'm writing to this
> mailing list because I'd like to contribute to the project by adding
> support of the aformentioned device.
>  From what I can see, there's already an open PR
> (https://github.com/openwrt/openwrt/pull/3762). I've merged the current
> master into my fork (https://github.com/eutampieri/openwrt) and I've
> built it. I can boot it from ramdisk but as soon as I flash the
> sysupgrade I get this into the serial log:
>  >|Kernel panic - not syncing: No working init found. Try passing init=
> option to kernel. See Linux Documentation/admin-guide/init.rst for
> guidance.|
> As far as I can tell, the init var isn't passed from the bootloader
> (uboot), but how can I fix this?

If you are running OpenWrt, the message about a missed init executable
file means that you had some issues with a rootfs partition. OpenWrt
uses the default init path, so there is no need to specify it
manually. So if the kernel reports it can not find a working init,
then the init was really missed.

> Thanks to Benjamin Kallus we've found that the problem may lay here:
>
>     [    0.433506] 0x000002280000-0x000003f40000 : "firmware"
>     [    0.441125] 2 uimage-fw partitions found on MTD device firmware
>     [    0.447182] Creating 2 MTD partitions on "firmware":
>     [    0.452225] 0x000000000000-0x0000005c0000 : "kernel"
>     [    0.458674] 0x0000005c0000-0x000001cc0000 : "rootfs"
>     [    0.464437] mtd: device 12 (rootfs) set to be root filesystem
>     [    0.471011] mtdsplit: no squashfs found in "rootfs"
>
> When I download the mtdblock for rootfs, I get
>
>
>     DECIMAL       HEXADECIMAL     DESCRIPTION
>     --------------------------------------------------------------------------------
>     0             0x0             JFFS2 filesystem, big endian
>     10223696      0x9C0050        Zlib compressed data, compressed
>     10224308      0x9C02B4        Zlib compressed data, compressed
>     10225004      0x9C056C        Zlib compressed data, compressed

It looks like a sysupgrade image you used to flash your device lacks
the rootfs part. The JFFS2 signature that you see was written by the
firmware on first boot. Check your sysupgrade image with binwalk to
make sure.

OpenWrt produces several output files, what file exactly did you use
to flash the device. Does its name contain the 'squashfs-sysupgrade'
suffix?

I also noticed that you merged Albinhe's commit to the latest OpenWrt
version. Merging can cause unintentional breaking of the firmware
image build. Try to build and flash clean unmerged code, possibly just
from the Albinhe tree. If the clean version boots successfully, then
something went wrong during the merge with the upstream master branch.
If the clean version also fails to boot, then a deeper investigation
into the build process will be required

> Il 25/02/22 14:23, Benjamin Kallus ha scritto:
>> That's right; the rootfs doesn't need specific offsets, you just need
>> to tell the kernel which partition to use as the rootfs on the kernel
>> command line. Good luck getting things working!
>>
>> On Fri, Feb 25, 2022 at 1:15 PM Eugenio Tampieri
>> <eugenio at eutampieri.eu> wrote:
>>
>>     First of all, thanks for your reply.
>>     Second thing, sorry for the empty subject in my previous email. I
>>     was caught off guard by the (totally sane and agreeable) rejection
>>     of multipart HTML emails so I missed the subject.
>>
>>     About the rootfs: I already have the dumps, just not with me. I'll
>>     try with different offsets. Does the rootfs partition need to have
>>     a particular label (i.e. rootfs)? I thought that by pointing the
>>     bootloader to it was enough.

-- 
Sergey