[RFC] MDIO firmware upload for offloading CPU

[RFC] MDIO firmware upload for offloading CPU

[Andreas Böhler]

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?

Thanks,
Andreas

Re: [RFC] MDIO firmware upload for offloading CPU

[Andrew Lunn]

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

Re: [RFC] MDIO firmware upload for offloading CPU

[Andreas Böhler]

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

Re: [RFC] MDIO firmware upload for offloading CPU

[Andrew Lunn]

> > 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.

O.K. That makes it more difficult. Does probing just these four PHYs
upset the firmware upload? You need to probe them in order to use
them.

> > 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

So the traditional model would be, the driver on the Lantiq for the
interfaces would be responsible for downloading the firmware to the
Atheros. Is there a driver for the ath9k-htc transport? That transport
is probably specific to the Atheros chip. So you can do the firmware
download from there.

Do you only use one address on the MDIO bus for firmware download?
Another option would be to have an mdio 'device' with a driver. When
the MDIO bus is enumerated by of_mdiobus_register(), it would find
this 'device' in DT, and load the driver for it. That driver could
then download the firmware over MDIO, and then later Ethernet. All the
infrastructure is in place for this. It is used by Ethernet switches
on MDIO busses.

	 Andrew