Allwinner A10 based Miracast DLNA HDMI Dongle

[Adrian N]

Hello sunxi people!

This is my first participation in this group.

I've bought an Anycast HDMI Mircast dongle (one of the many clones that resembles a Chromecast first gen). I cracked it open and found out it is based on the Allwinner A10, which was a great surprise because I was expecting Rockchip.

The date on the PCB is 2019.10.10, fairly new, so I expect this is a new model. Has anybody else come across these type of boards? I'm interested in replacing the original firmware (which is very unstable) with anything linux based that will provide miracast sceen mirroring.

The PCB is red, has a text label SP-X11-V2.0, has the A10 SoC, the flash, the sram, some voltage regulators, a blue LED, a button and the micro-usb that is used for providing power and for the connection of an additional WIFI dongle based on a Realtek chip.

This board has very little ram and flash (and no SD card) so I'm certain android cannot fit. It will certainly need a linux only firmware. I'm aware of the many hdmi + android mini-PCs that are somewhat similar, but I can't use those firmwares.

If I connect the board to my (linux mint) laptop via usb while keeping the button pressed, running lsusb will show "Bus 001 Device 066: ID 1f3a:efe8 Onda (unverified) V972 tablet in flashing mode". Can I somewhow dump the original firmware to look at it ?

I'm not a linux dev, so I'm a very green newbie here. If anybody can help with advice I would be very grateful.

I've attached some pictures of the PCB, maybe it helps to identify it.

Thanks!

[Nazım Gediz AYDINDOĞMUŞ]

Hello Adrian,

It looks like a cool device.

I think you may be able to dump the original firmware using
"spiflash-read" command of the sunxi-fel tool after you boot the device
into the FEL mode.

By the way, some of the information there is outdated but the rest may
be useful in the following wiki page:
http://linux-sunxi.org/Retrieving_device_information

Regards,
Gediz

[Adrian N]

 Hi Gediz,

I followed the wiki, checked out from git repo, installed required deps and built sunxi tools successfully. Then I was able to put the device in FEL mode by keeping the button pressed when plugging the usb.

This is the output I get from running sudo ./sunxi-fel version
AWUSBFEX soc=00001623(A10) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000

But attempts to read anything from it are failing with time out.

  sudo ./sunxi-fel read 0x42400000 0x82d0 boot1.header

  sudo ./sunxi-fel read 0x43000000 0x20000 script.bin

The exact error message is: usb_bulk_send() ERROR -7: Operation timed out

What could be the cause of this ?

[Adrian N]

I only noticed now Gediz that you mentioned 'spiflash-read', not 'read'. So I tried again. No luck.

sudo ./sunxi-fel spiflash-info

says:    

SPI support not implemented yet for 1623 (A10)!

So what are the options now?

[Adrian N]

But, maybe the timeout is caused by the device not really having that much memory.

So I tried with a lower address, sudo ./sunxi-fel read 0x0 0x90000 xxxx.bin and it did work

I'll try to guess the capacity of the flash and dump it all. But what next ? :)

[Nazım Gediz AYDINDOĞMUŞ]

On 10.09.2020 13:02, Adrian N wrote:
>  Hi Gediz,
>
> I followed the wiki, checked out from git repo, installed required deps
> and built sunxi tools successfully. Then I was able to put the device in
> FEL mode by keeping the button pressed when plugging the usb.
> This is the output I get from running sudo ./sunxi-fel version
> AWUSBFEX soc=00001623(A10) 00000001 ver=0001 44 08 scratchpad=00007e00
> 00000000 00000000

That's good news.

> But attempts to read anything from it are failing with time out.
>   sudo ./sunxi-fel read 0x42400000 0x82d0 boot1.header
>   sudo ./sunxi-fel read 0x43000000 0x20000 script.bin
>
> The exact error message is: usb_bulk_send() ERROR -7: Operation timed out
>
> What could be the cause of this ?

Memory space for A10 (sun4i) starts from 0x40000000 according to the
memory map (http://linux-sunxi.org/Memory_map). 0x42400000 and
0x43000000 are in the range of the general memory space so this is an
attempt to reach the DRAM. If DRAM memory controller is not initialized
yet, trying to access to the mentioned addresses may fail. You may
consider using "sunxi-fel spl" or "sunxi-fel uboot" commands and
initialize the DRAM first. But you would need an SPL (sunxi-spl.bin) or
U-Boot (u-boot-sunxi-with) file, produced by U-Boot. Further information
can be found on the help output of the sunxi-fel tool.

On 10.09.2020 15:09, Adrian N wrote:
> I only noticed now Gediz that you mentioned 'spiflash-read', not 'read'.
> So I tried again. No luck.
>
> sudo ./sunxi-fel spiflash-info
>
> says:
>
> SPI support not implemented yet for 1623 (A10)!
>
> So what are the options now?

It's really interesting because as far as I know, SPI flash controller
of A10, A13 and A20 are too much similar if not completely same and
apparently A13 and A20 are supported by sunxi-fel. I did not work with
any board that is powered by A10 before but the first thing I'd do is a
dirty hack: adding 0x1623 to the list of the supported devices (in here
https://github.com/linux-sunxi/sunxi-tools/blob/7fe6024211ffed3024b0491ee9f2a19c17848c12/fel-spiflash.c#L154)
and see the result. I really have no other idea.

On 10.09.2020 15:36, Adrian N wrote:
> But, maybe the timeout is caused by the device not really having that
> much memory.
> So I tried with a lower address, sudo ./sunxi-fel read 0x0 0x90000
> xxxx.bin and it did work

According to the memory map, again, SRAM (on-chip RAM which does not
require an external init routine) starts from address 0x0 and goes until
0x0002ffff. But 0x90000 exceeds even after the Bank B of the SRAM so
0x90000 is probably not a valid address. So "xxxx.bin" is partly the
contents of the SRAM, and remaining part is most likely zero filled.

[Adrian N]

That was an awesome tip Gediz!

I added the line:

   case 0x1623: /* Allwinner A10 */

right before this line: https://github.com/linux-sunxi/sunxi-tools/blob/7fe6024211ffed3024b0491ee9f2a19c17848c12/fel-spiflash.c#L163

because it seems A10 is actually more similar to A20 in terms of booting from spi flash than A13 (line 154 that you suggested).

I tried both variants, but it worked only after adding before line 163.

So now spiflash-info command succeeds and tells me it's a Macronix 16 MB flash.

I was able to dump it, and then running strings command on it yielded some very interesting strings:

eGON.BT0
sunxi-cubieboarda10
sunxi SPI
U-Boot SPL 2019.10 (Oct 15 2019 - 20:11:30 +0800)
U-Boot 2017.01-rc2-00098-gc88edf
bootcmd=sf probe 0; sf read 0x41000000 0x80000 0x400000; bootz 0x41000000
bootdelay=0
baudrate=115200
arch=arm
cpu=armv7
board=sunxi
board_name=sunxi
soc=sunxi
stdin=serial
stdout=serial
stderr=serial
bootm_size=0xa000000
kernel_addr_r=0x42000000
fdt_addr_r=0x43000000
scriptaddr=0x43100000
pxefile_addr_r=0x43200000
ramdisk_addr_r=0x43300000
dfu_alt_info_ram=kernel ram 0x42000000 0x1000000;fdt ram 0x43000000 0x100000;ramdisk ram 0x43300000 0x4000000
fdtfile=sun4i-a10-cubieboard.dtb
console=ttyS0,115200
boot_prefixes=/ /boot/
boot_scripts=boot.scr.uimg boot.scr
boot_script_dhcp=boot.scr.uimg
boot_targets=fel

This list is only partial. I'm not going to put here the full list because it is very long. I also cannot post publicly the contents of the SPI flash for obvious reasons.

My goal is now to extract some useful config info from this dump to be able to re-create from scratch a fully open-source and very small firmware based on linux by following the steps from https://linux-sunxi.org/New_Device_howto

The biggest problems are the flash and SDRAM of this device are very limited: 16MB flash, 128 MBytes DDR2 RAM (based on the ELIXIR N2TU1G16GG-AC label on the chip). Is that too little ?

Btw, it would be good to add that one-line patch to git master. I'll make a PR next week.

I also found 3 unmarked round pads that might be the serial console, but I cannot confirm that yet.

Thanks a lot!

[Adrian N]

Hi,

I've created a trivial PR for adding SPI flash support for A10 :   https://github.com/linux-sunxi/sunxi-tools/pull/138

It seems that nothing more was needed, just adding the ID to the supported list.

Thanks!

[Nazım Gediz AYDINDOĞMUŞ]

You're welcome. I'm glad it worked out. It would be even better to be
able to debug the board with a console. I think 128 MBs of DRAM and 16
MBs of SPI flash can easily handle a modest application. You can do it.

On 14.09.2020 10:27, Adrian N wrote:
> Hi,
>
> I've created a trivial PR for adding SPI flash support for A10 :
> https://github.com/linux-sunxi/sunxi-tools/pull/138
> It seems that nothing more was needed, just adding the ID to the
> supported list.
>
> Thanks!

That's cool. Our next fellow hacker won't have to tinker around. And I
admire you, by the way. I'm using sunxi-fel for around two years and did
not have an opportunity to contribute to the tool :)

So, thank you too!

[Adrian N]

Gediz, all credit should go to you! I couldn't have done anything without your tips.

I think I would be able to re-create a small image from scratch, with the bare necessities, an ip stack, wifi, busybox, telnet or ssh.

But not sure the final goal of making this little board work with hdmi output + miracast and / or dlna is actually attainable.

Could not find any opensource projects for that, especially one that could fit in this very constrained environment.

Adrian

[Clément Péron]

Hi Adrian,

Le mar. 15 sept. 2020 à 13:06, Adrian N <ani...@gmail.com> a écrit :
>
> Gediz, all credit should go to you! I couldn't have done anything without your tips.
>
> I think I would be able to re-create a small image from scratch, with the bare necessities, an ip stack, wifi, busybox, telnet or ssh.
>
> But not sure the final goal of making this little board work with hdmi output + miracast and / or dlna is actually attainable.

Just my advice here but don't rewrite a build system from scratch use
buildroot or yocto.
Buildroot is very easy to understand / Yocto more powerful
https://git.buildroot.net/buildroot/tree/package/miraclecast?h=master
https://github.com/OSSystems/meta-miracast/blob/master/recipes-miracast/miraclecast/miraclecast_git.bb
Both have a package/recipe for miraclecast.

In your case, I would choose buildroot.

Add the board config, make the uart / wifi / hdmi works. (Mainline it
to buildroot :P)
Then I think the last thing is to write the gstreamer pipeline to
connect the miraclecast sink to cedrus and you're good.

Good luck,
Clement

> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CAAuDtmd9V%3DWj4gK7u%3Dw%2Bqgwnq7f6zLdV906qsxWFdWbh148RNg%40mail.gmail.com.

[Adrian N]

Hi,

I had a look at buildroot, seems neat. Thanks for the tip!

As for miraclecast, I don't know... I had some prior experience with it. Almost forgot about it. But I've just tried the latest version today and, again, out of 4 android devices I own only one can connect to my miraclecast sink running on my linux mint 20 on a very new thinkpad p1 with intel chipset. Some blame it on the intel chipset actually and say it works better on other wifi chipsets :).  Maybe that's true. I'll try to run it on the a10 dongle, but I doubt I'll have enough time for this project this week.

My other 3 android devices fail to connect for mysterious unspecific reasons. Usually timeout, but the actual cause is not clear. I activated trace logging on the miracle sink and also on the miracle-wifid but could not figure out. So from my point of view miraclecast is a pretty experimental project ATM that offers similar reliability as the original firmware on these cheap hdmi miracast dongles. At least my success rate was identical :) So I'd rather look for an alternative :)