stability proposals for the yun faq

Hi I had some time/energy to play with the yun yesterday and I found 2 changes that I like and I would like to add to the yun FAQ but I would like to get some input before I do so. So here I go:

Some important information to understand about (re)booting the Yun 1)When the Yun is powering up both the Leonardo and the Linux part are booting up. This means that at this time both processors start at the same time. 2)When the Leonardo part is rebooted (due to upload, rest button, reset-mcu command,....) the Linux keeps on running. 3)When the Linux part is rebooted (due to reboot command, reset button, upgrade,...) the Leonardo part keeps on running. It is important to understand that those are 3 different situations and the behavior in the 3 situations is different. Why? When the Linux part is booting it sends and reads information on the serial port /dev/ttyATH0. On the Leonardo part that is Serial1 (used by the bridge or your bridge replacement). If the Leonardo responds to the booting information of the Linux; it is very likely (not to say it is guaranteed) that the Linux will not finish its booting process. note:As the information Linux is transmitting is your life saver when things go really bad you do not want this behavior to go away.

Therefore it is important to know the state the other processor is in. However there is currently no way to know that (and frankly if you knew it won't be nice and easy code) So what are the workarounds?

Case 1 is catered by the bridge (and that is why it can take a very long time for the bridge to startup) but if you use serial1 without the bridge you will need the same code in your setup() method

  Serial1.begin(115200); // Set the baud.
// Wait for U-boot to finish startup.  Consume all bytes until we are done.
  do {
     while (Serial1.available() > 0) {
        Serial1.read();
        }
    delay(1000);
  } while (Serial1.available()>0);

case2: As the problem only happens when the Linux part is rebooting: case 2 is not a problem as Linux is not booting.

Case 3: when you use the reboot command on Linux. Make a new file called /bin/reboot with following content

reset-mcu
/sbin/reboot

make the file executable

chmod +x /bin/reboot

After this change a reboot command will reboot the Leonardo together with the Linux and case 3 becomes case 1

When you do a upgrade: upload the barebones example sketch to your yun.

I don't know what happens when you press the Linux reset button. Some input there is appreciated. So are other constructive comments.

Best regards Janje

Making the linux reboot command also reset the mcu seems a good idea. Have you tried it? Is it working? I'm not sure about the timing, since reset-mcu is immediate, while reboot takes a few seconds)

With "linux reset button" you mean the side one, the one to keep pressed for more than 30 seconds? If that is the case, overlay gets flagged for formatting at next reboot (at least that what I understood) and then yun is reboot with reboot command

[quote author=Federico Fissore link=topic=241372.msg1730876#msg1730876 date=1400586599] Making the linux reboot command also reset the mcu seems a good idea. Have you tried it? Is it working? I'm not sure about the timing, since reset-mcu is immediate, while reboot takes a few seconds) [/quote] I use it. Seems to work fine since I added it. I have however another delay of 2 seconds in my setup. so maybe i should say

delay(2000); //compensate for the faster reboot of leonardo to linux.  
Serial1.begin(115200); // Set the baud.
// Wait for U-boot to finish startup.  Consume all bytes until we are done.
  do {
     while (Serial1.available() > 0) {
        Serial1.read();
        }
    delay(1000);
  } while (Serial1.available()>0)

[quote author=Federico Fissore link=topic=241372.msg1730876#msg1730876 date=1400586599] With "linux reset button" you mean the side one, the one to keep pressed for more than 30 seconds? If that is the case, overlay gets flagged for formatting at next reboot (at least that what I understood) and then yun is reboot with reboot command [/quote] That is the button indeed. I however fail to understand the middle part of the explanation. And the last part is reboot or /sbin/reboot. and in case of reboot is /bin in the path (I guess it is).

Now I think of it. I'd better add that this takes away the need for reset-mcu in /etc/rc-local.

Best regards Jantje

Jantje: That is the button indeed. I however fail to understand the middle part of the explanation. And the last part is reboot or /sbin/reboot. and in case of reboot is /bin in the path (I guess it is).

Code speaks better: when you press that button, a thing called "triggerhappy" executes the first script in this file https://github.com/arduino/openwrt-packages-yun/blob/master/arduino/yun-conf/files/etc/triggerhappy/triggers.d/reset.conf When it's released, it executes the second one.

This is the script: https://github.com/arduino/openwrt-packages-yun/blob/master/arduino/yun-scripts/files/usr/bin/wifi-reset-button-released The actual command executed is here: reset-to-factory-anyway && reboot So, if we wish to use a reboot++, we have to specify the full path

https://github.com/arduino/openwrt-packages-yun/blob/master/arduino/yun-scripts/files/usr/bin/wifi-reset-and-reboot a reset-mcu on line 21 should do the reset (so should simply calling reboot) the reset to factory default should work wit the change I propose (adding reboot in /bin)

That should make rebooting linux failsafe with the bridge or the code as I proposed. there is still upgrading though.

Best regards Jantje

Tracking with https://github.com/arduino/openwrt-packages-yun/issues/3

I updated the playground. Jantje

If the Leonardo responds to the booting information of the Linux; it is very likely (not to say it is guaranteed) that the Linux will not finish its booting process.

Why is this?

Are all the ways to 'reboot' the linux side making use of the 'reboot' command?

E.g. suppose the linux side has completely crashed, and it can not execute anything anymore, how would you be able to recover from such a state.

NewLine:

If the Leonardo responds to the booting information of the Linux; it is very likely (not to say it is guaranteed) that the Linux will not finish its booting process.

Why is this?

I don't know.

NewLine: Are all the ways to 'reboot' the linux side making use of the 'reboot' command?

No as you can see from the discussion and the playground.

NewLine: E.g. suppose the linux side has completely crashed, and it can not execute anything anymore, how would you be able to recover from such a state.

A crash is what I try to avoid. I assume the watchdog should start a reboot. @Federico Do you know which script the watchdog runs when the linux fails? Does it run reboot or /sbin/reboot?

Jantje

Jantje:

NewLine:

If the Leonardo responds to the booting information of the Linux; it is very likely (not to say it is guaranteed) that the Linux will not finish its booting process.

Why is this?

I don't know.

NewLine: Are all the ways to 'reboot' the linux side making use of the 'reboot' command?

No as you can see from the discussion and the playground.

Oh that is bad....means it will not be able to boot as long as the mcu does not get restarted (if the mcu sketch sends stuff over the bridge), right?

NewLine: Why is this?

Because uboot (the very first thing run by the linux side when you power it on) has "Hit any key to stop autoboot" message. If some byte gets sent in those 5 seconds, you'll enter uboot console and never have linux started

NewLine: Oh that is bad....means it will not be able to boot as long as the mcu does not get restarted (if the mcu sketch sends stuff over the bridge), right?

Right

Jantje: Do you know which script the watchdog runs when the linux fails? Does it run reboot or /sbin/reboot?

As far as I understand it, it's a hardware thing. I guess that when triggered, it will perform a "hard reset" like when you press the YUN RTS button

yesterday I had an instance -out of many- where my reboot didn't work. My sketch was in a sending mode all the time (send something every 500 milllis) I rebooted due to "issues" so it may have taken a bit longer to reboot. I'm considering to increase the 2 seconds delay to 3 to be on a safer side. Do you have any clue on how long the reboot is delayed? And how long uboot takes at most to start sending to the serial port?

Best regards Jantje

We may find a minimum amount of time but it really depends on how many things you're running. Say you have set up the yun with a swap file and have lots of services and a couple of nodejs webapps running: reboot time will be much longer

I updated the faq accordingly

I solved the "Hit any key to stop autoboot" problem with the mcu sending data to u-boot and stopping the boot process.

Basically, it makes the user type "yun" to stop autoboot if they want to get to the u-boot prompt. It's exactly how tp-link routers work with typing "tpl" to stop autoboot.

It does require an upgrade to u-boot and if that goes wrong you brick the Yun. The only way to recover after that is to desolder the flash and go through the whole process of writing a new image and soldering the chip back on.

I used https://github.com/pepe2k/u-boot_mod to create a new bootloader with the typing "yun" option and adding some other features to u-boot like a custom web server upload for new firmware.

arbor: I solved the "Hit any key to stop autoboot" problem with the mcu sending data to u-boot and stopping the boot process.

Basically, it makes the user type "yun" to stop autoboot if they want to get to the u-boot prompt. It's exactly how tp-link routers work with typing "tpl" to stop autoboot.

It does require an upgrade to u-boot and if that goes wrong you brick the Yun. The only way to recover after that is to desolder the flash and go through the whole process of writing a new image and soldering the chip back on.

I used https://github.com/pepe2k/u-boot_mod to create a new bootloader with the typing "yun" option and adding some other features to u-boot like a custom web server upload for new firmware.

first class work! an other two reasons u-boot should updated:

  • type "yun" to stop autoboot
  • custom web server upload for new firmware, art, as well as u-boot itself

arbor: I solved the "Hit any key to stop autoboot" problem with the mcu sending data to u-boot and stopping the boot process.

It does require an upgrade to u-boot and if that goes wrong you brick the Yun. The only way to recover after that is to desolder the flash and go through the whole process of writing a new image and soldering the chip back

Sorry for my ignorance, but does this become less risky when moving the root file system from flash to the sd card as in http://forum.arduino.cc/index.php?topic=236696.msg1701441#msg1701441

NewLine:

arbor: I solved the "Hit any key to stop autoboot" problem with the mcu sending data to u-boot and stopping the boot process.

It does require an upgrade to u-boot and if that goes wrong you brick the Yun. The only way to recover after that is to desolder the flash and go through the whole process of writing a new image and soldering the chip back

Sorry for my ignorance, but does this become less risky when moving the root file system from flash to the sd card as in http://forum.arduino.cc/index.php?topic=236696.msg1701441#msg1701441

U-boot is the first 256k of flash on the Atheros side. It's separate from the Rootfs. When the Atheros turns on it looks for a bootloader at the beginning of the flash and runs u-boot. If U-boot is not there or is corrupted then nothing will happen on the Atheros side and the Yun is bricked.

Not that upgrading u-boot isn't safe or fails often with a good working image. But if it does it becomes a pain of a problem.

NewLine: ... Sorry for my ignorance, but does this become less risky when moving the root file system from flash to the sd card as in http://forum.arduino.cc/index.php?topic=236696.msg1701441#msg1701441

The link you provide will give you "pivot overlay" and not complete root file to the sd card.

for complete root file - "pivot root"

http://forum.arduino.cc/index.php?topic=228204.msg1651254#msg1651254

http://forum.arduino.cc/index.php?topic=228204.msg1653830#msg1653830