Updated paragraph
Since the first release of April 17th, 2014, more changes and improvements were piled on the stack. You can now read the complete list in the change log.
We called this image OpenWrt-Yún because it’s now based on the stable version of OpenWrt, OpenWrt 12.09 Attitude Adjustment. This makes it much easier to build and develop. Previous Yún image version was mostly impossible to build: this version compiles from the beginning to the end. Detailed instructions about setting a build machine are available at GitHub - arduino/openwrt-yun: A custom version of OpenWrt, targeted to the Arduino Yún.
The first Yún shipping the new image has serial number Y00030600.
Thanks to git, OpenWrt-Yún is synchronized with official OpenWrt: we continuously get and build fixes and improvements. To give back to the OpenWrt community and to allow the curious to quickly discover the differences between Yún and OpenWrt, every time we add a change we update branch "rebased_master". It keeps all our modifications on top of the list, thus making it easier to discover how OpenWrt was customized.
Following OpenWrt source files organization, Yún specific packages have their own repository: GitHub - arduino/openwrt-packages-yun. If you wish to contribute to the list of available packages, this is where to send your pull requests and to open your issues.
We really hope you’ll be able to discover a new Yún, more stable and reliable. We’d also like to see you more involved into Yún internals, now that it’s easier to build it.
Forgot a detail:
Next IDE version will contain updated examples, a new Mailbox example and an updated Spacebrew library. If you are in a hurry, you can download the nightly. http://arduino.cc/en/Main/Software#toc4
Robin2:
When can we expect the new version to be on Yun boards as standard?
Newest batch of boards will ship this version
Robin2:
How will we be able to tell whether a supplier has the old or the new version?
The new version lights up the USB led when the linux side is ready, old one does not. A coming update will show the version number on top of the webpanel page (there is a issue to track this Add image version info to configuration screen · Issue #2 · arduino/openwrt-yun · GitHub)
I should also be notified of the first board number with the new image: as soon as I know, I'll post that number here, so you'll know if you're buying a yun with the old image or not.
Robin2:
Can you arrange for a member of the development team to participate regularly in this Yun section of the Forum?
No. We gave a spin to the SPI Bridge of linino.org but found that it was incomplete: it supported only Bridge.get and put methods, not Process or anything else. Things may have changed since then, though.
Not as far as I understood the writing. The resistor improves the responsiveness of the auto detect feature. But to be honest, I would be glad to have a real Linino state flag in my sketch even it takes a few seconds longer.
I'll give that a try, it seems cool stuff and not hard to implement on the Bridge side. I'm worried about the hardware though. I'll let you know how it goes.
mamu:
Btw: good to have you back here.. I missed you.
+1
I have upgraded a yun now. It went so smooth I doubth I upgraded at all.
When I started configuring all went well (yun, cifs, tty, usb-acm,minicom...) except for
Yun didn't find my wifi access point (probably it found it but didn't list it due to to many access points).
But connected directly when name is provided (fortunately for me I know my protocol by heart)
The mega that was connected during the whole protocol now has a broken USB port. Better be safe than sorry: disconnect all peripheral before doing the upgrade.
FYI I've changed last "Bridge solved issue" line to
Bridge is now run with "-u" python flag, preventing some random lockups in the Bridge
as the 64K issue is not related.
If you run into troubles using some Process.run with large outputs, you must use the asynchronous version. Since Bridge (with Process.run) is waiting for the process to end before start consuming its output and since Linux is waiting for the output to be consumed before putting more into the buffer, they both will block. With the asynchronous version, output is immediately consumed by bridge
I upgraded one of my Yun's yesterday. I completed the upgrade over the network and all went smoothly. Took me about an hour, including re-installing packages and restoring my own scripts
Really good to see we can use all the OpenWRT packages, so I won't have to install nginx manually.
For the moment I am using the uhttpd server for my PHP application. Interestingly, a bit of javascript which had been causing one of the pages to crash fcgi , after being left open in a browser for a couple hours, has been running Ok all night.
So to Fredrico and anyone else who may have contributed, you have my thanks.
I've proceeded with the recommended upgrade. But now, when my Yun is connected to the network, the arp -a command doesn't list arduino but host-001 instead —192.168.1.24 is the address of the Yun.
# uname -a
Linux myYun 3.3.8 #1 Fri Apr 11 07:16:38 CEST 2014 mips GNU/Linux
$ arp -a
mac (192.168.1.1) at 11:22:33:44:55:66 on en1 ifscope [ethernet]
host-001 (192.168.1.24) at cc:dd:ee:ff:00:11:22 on en1 ifscope [ethernet]
router.lan (192.168.1.254) at 77:88:99:aa:bb:cc on en1 ifscope [ethernet]
Even performing a sudo arp -d -a didn't solve the problem.
Are you experiencing something similar? Thank you!
I installed it from a USB stick as mentioned earlier in this thread, worked like a charm. I got everything re-configured as I had it before. A couple of minor questions:
I copied my Mac id_rsa_pub key to ~/.ssh/authorized_keys on the Yun, but I still have to enter my password when I ssh into the Yun. This worked for the old image, did I forget something, or has this changed in the new image ?
I think I remember some talk about being able to upload via the IDE without password, I never did get that to work (on the old or new image). There was some allusion to a new version of the IDE which would allow this, did this ever happen ?