Port Arduino Yun to ath79


I'm currently working on porting Arduino Yun to ath79 target.

It seems like Yun (on ar71xx) was left unattended for a while. Its console and sysupgrade broke down two years ago, but no follow-up fix patches were not submitted.

I hope someone here could review and/or test my patches. There are several variants and revisions of Yun out there, so I'd also like to get some information about them.


1 Like

Hi @mans0n

some more information that might make it into your PR

I did a port to 18.xx a while back as part of a reverse engineering adventure on Arduino's repo as well as some partial porting on this forum . It will turn a Yun in to a "standard" openwrt device with an extra microcontroller as it doesnt use their Juci "web desktop thing" and Arduino's utility scripts, but AVRdude works to upload code to the local 32u4 mcu as long as one has created the SPI port with spi-gpio-custom in a startup script, or defined it in the DTS using spi-gpio and spidev.

The pin mapping is as follows ( not always clear from their schematics or setup)
ar9331 GPIO : function
26 : bitbang SPI SS ( used in spi-gpio-custom to create /dev/spi1.0 )
27 : bitbang SPI MOSI
8 : bitbang SPI MISO
11 : bitbang SPI SCK
21 : SPI level shifter enable
19 : AVR handsake signal ( has 10k pullup )
6 : GP6 on arduino pcb
22 : handshake and GP6 level shifter enable
23 : UART level shifter enable
18 : AVR reset
20 : configuration button
1 : LED0 : Wireless LED (blue)
0 : LED1 : USB/System Led (White)
17 : LED6 : LAN led (yellow)

I also added another pinmux definitions to the ar9330.dtsi to use gpio 11 as GPIO on any AR9331 device , pone also needs to use jtag-disable and jumpstart_disable to use GPIO26 and 27

pinmux_extended: pinmux-extended@18040030 {
				compatible = "pinctrl-single";
				reg = <0x18040030 0x4>;

				pinctrl-single,register-width = <32>;
				pinctrl-single,function-mask = <0x1>;
				#pinctrl-cells = <2>;

				//Extended GPIO Function Control GPIO_FUNCTION_2 bit9 ( 0x200) disabled jumpstart and ste GPIO11 as a GPIO )
				jumpstart_disable: pinmux_jumpstart_disable {
					pinctrl-single,bits = <0x0 0x200 0x200>;
				//Extended GPIO Function Control GPIO_FUNCTION_2 bit8 ( 0x200) disabled jumpstart  )
				wps_disable: pinmux_wps_disable {
					pinctrl-single,bits = <0x0 0x100 0x100>;

pinmux_mdio: pinmux_mdio@180600ac {
				compatible = "pinctrl-single";
				reg = <0x180600AC 0x4>;

				pinctrl-single,register-width = <32>;
				pinctrl-single,function-mask = <0x1>;
				#pinctrl-cells = <2>;

				mdio_gpio: pinmux_mdio_gpio {
					pinctrl-single,bits = <0x0 0x40000 0x40000>;


My arduino-yun devicetree file is at this Gist , but its the only thing that differs from yours in my port (network, boards and leds files look similar),

I set the GPIO directions in dts using gpio-export,output = <1>; instead of gpio-hog as they will still be available for user scripts to manipulate from sysfs later on- on newer kernels gpio-hog doenst allow the hogged gpio's to be manipulated/ exported to sysfs.

I also set my baudrate to 115200 instead of including the baudrate patch to allow it to speak at 250000 - I connect to my "Yuns" using usb-Serial adapters while running code on the 32u4 so 115200 was a convenient choice and I use SPI or I2C to speak to the 32u4 instead of bridge/serial library and thus had no need for the 250000 baudrate support.
it would be nice f that patch made it into OpenWRT tho..

@DDK Thanks for your quick comment! :slight_smile:

I also confirm that avrdude spigpio works on Yun with OpenWrt snapshot. We can no longer use spi-gpio-custom on ath79 as it has been marked broken since kernel 4.19, so that is not an option. And I'd like to give a way to use those bitbang spi pins for other uses (like second handshake or bitbang i2c? I don't know), so I didn't use spi-gpio as we cannot unload spi-gpio module (spi-gpio is built-in for ath79).

I've added two pinmux nodes to yun.dts. We might be able to move them to ar9330.dtsi as you did.

As for gpio-export, I did not add gpios other than three enable pins, because reset and handshake pins might work for input. (Three OE pins do not share lines with other output pins, so we're safe to mark them "output".) We might be able to use "gpio-export,direction_may_change" property, though...

I've added working boot console patch so we can continue to use 250000 baud rate safely. In that way we don't need to change U-Boot env to make bootloader console work.