From: Andrew Lunn <andrew@lunn.ch>
To: "Andreas Böhler" <news@aboehler.at>
Cc: netdev@vger.kernel.org
Subject: Re: [RFC] MDIO firmware upload for offloading CPU
Date: Sun, 22 Mar 2020 15:43:06 +0100 [thread overview]
Message-ID: <20200322144306.GI11481@lunn.ch> (raw)
In-Reply-To: <27780925-4a60-f922-e1ed-e8e43a9cc8a2@aboehler.at>
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?
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.
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.
Andrew
next prev parent reply other threads:[~2020-03-22 14:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-22 13:56 [RFC] MDIO firmware upload for offloading CPU Andreas Böhler
2020-03-22 14:43 ` Andrew Lunn [this message]
2020-03-22 20:29 ` Andreas Böhler
2020-03-22 21:09 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200322144306.GI11481@lunn.ch \
--to=andrew@lunn.ch \
--cc=netdev@vger.kernel.org \
--cc=news@aboehler.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).