[Arm-netbook] awusb (activewire usb?) usbmon wireshark pcap dump

Henrik Nordström henrik at henriknordstrom.net
Fri May 3 02:10:43 BST 2013


tor 2013-05-02 klockan 22:21 +0100 skrev luke.leighton:

> but i've taken, as the subject line says, a dump of the awusb activity
> when running livesuit to flash an image to the a10 eoma68 card.  i got
> to the "do you want to erase the nand" bit and it flipped the usb bus
> from 002 to 001 so i didn't see the 4gbyte download.  however you can
> clearly see the word "DRAM" in the transfer before that point.  also
> there is the string "AWUSBFEL" quite early on, from the client.

The FEL protocol have already been reverse engineered in detail. Both
the protocol used by the boot ROM, and also the protocol used after the
flasher application takes over.

>From a free software perspective what happens after the flip is
irrelevant. It's just two parts of a proprietary software talking to
each other.

> it may turn out to be quite easy to identify what's going on, here,
> which would be great.  if this is similar to "activewire usb" then it
> may be as simple as loading and executing some code, or
> reading/writing to memory locations.

Yes it is trivial and we already do. See for example fel-gpio in
sunxi-tools.

> my hypothesis is that the "flip" on the USB bus was the activation of
> some code on the A10, which reset the bus and then re-ran the FEL mode
> startup in order to receive the NAND flash data.

The "flip" is the activation of the uploaded flasher program which takes
over the USB bus from the FEL ROM.

> i see no reason why
> this should not be completely ignored, and the AWUSBFEL process used
> to upload e.g. spl and u-boot.

We can in theory upload SPL via FEL, but at the moment lack USB drivers
in SPL to then upload the full u-boot.

A more workable approach in terms of FEL would be to make another board
strap program based on the DRAM & clock code we have in SPL but adapted
for FEL usage, then upload u-boot + kernel + initrd via FEL and start
u-boot. Well, we don't really need u-boot in that picture but it's
convenient for setting up the right boot arguments to the kernel. We
have done such boardstrap programs in the past during the early
experimentations on A13 for example, but nothing finished for actual
use, focus quickly moved to making u-boot SPL stable once we got the
basics working.

Regards
Henrik




More information about the arm-netbook mailing list