netdev - Re: [RFC] MDIO firmware upload for offloading CPU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 22 Mar 2020 21:29:21 +0100
From:   Andreas Böhler <news@...ehler.at>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org
Subject: Re: [RFC] MDIO firmware upload for offloading CPU

On 22/03/2020 15:43, Andrew Lunn wrote:
> On Sun, Mar 22, 2020 at 02:56:40PM +0100, Andreas Böhler wrote:
>> Hi,
>>
>> I'm working on support for AVM FRITZ!Box routers, specifically the 3390
>> and 3490. Both contain two SoCs: A Lantiq VDSL SoC that handles VDSL and
>> Ethernet connections and an Atheros SoC for WiFi. Only the Lantiq has
>> access to flash memory, the Atheros SoC requires firmware to be uploaded.
>>
>> AVM has implemented a two-stage firmware upload: The stage 1 firmware is
>> transferred via MDIO (there is no PHY), the stage 2 firmware is uploaded
>> via Ethernet. I've got basic support up and running, but I'm unsure how
>> to proceed:
>>
>> I implemented a user space utility that uses ioctls to upload the
>> firmware via MDIO. However, this only works when the switch
>> driver/ethernet driver is patched to allow MDIO writes to a fixed PHY
>> (actually, it now allows MDIO writes to an arbitrary address; I patched
>> the out-of-tree xrx200 driver for now). It is important to note that no
>> PHY probing must be done, as this confuses the target.
>>
>> 1. How should firmware uploads via MDIO be performed? Preferably in
>> userspace or in kernel space? Please keep in mind that the protocol is
>> entirely reverse-engineered.
>>
>> 2. If the firmware upload can/should be done in userspace, how do I best
>> get access to the MDIO bus?
>>
>> 3. What would be a suitable way to implement it?
> 
> Hi Andreas
> 
> You say there is no PHY. So is the MDIO bus used for anything other
> than firmware upload?

Yes - there are four other PHYs on the bus, everything is attached to
the Lantiq Gigabit switch. I wasn't clear enough in this regard.

> You can control scanning of the MDIO bus using mdio->phy_mask. If you
> set it to ~0, no scanning will be performed. It will then only probe
> for devices you have in device tree. If there are no devices on the
> bus, no probing will happen.

That sounds good.

> This two stage firmware upload is messy. If it had been just MDIO i
> would of said do it from the kernel, as part of the Atheros SoC WiFi
> driver. MDIO is a nice simple interface. Sending Ethernet frames is a
> bit harder. Still, if you can do it all in the wifi driver, i
> would. You can use phandle's to get references to the MDIO bus and the
> Ehernet interface. There are examples of this in net/dsa/dsa2.c.

A bit more info on the two-stage firmware upload: The Atheros SoC is a
complete AR9342 or QCA9558 SoC with 64MB or 128MB RAM. The stage 1
firmware only initializes the Ethernet connection and waits for the
stage 2 firmware. The latter consists in the vendor implementation of a
Linux kernel and minimal user space, the wireless cards are then somehow
"exported" over Ethernet to the Lantiq SoC. On the Lantiq, they look
like local Atheros interfaces  - it looks a lot like ath9k-htc with a
different transport

My current approach consists of a standalone Linux distribution (OpenWrt
based) that receives its configuration via Ethernet as stage 2 firmware.
This makes the second SoC quite capable.

To sum up: I've got two devices on one PCB where only one has access to
flash memory. The communication is entirely based on MDIO and Ethernet.

Regards,
Andreas