ath9k: support for Extreme Networks AP3805i

[Eugenio Tampieri]

> 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

Hello Sergey,

I have switched this mailing list to my p=none alias that should trick mailman (at least, according
to its docs) into not applying DMARC workarounds. Let me know if that worked or not.
I'm also bottom posting from now on. Sorry for my previous messages.

The image name did contain the 'squashfs-sysupgrade' suffix, but apparently it didn't get flashed
correctly because when I download mtd dumps and inspect them with jefferson I don't find a valid
openwrt root in any mtd.
I'll try to rebuild from the original contributor's repo and to check with binwalk my upgrade image
later this day.

Regards,

Eugenio