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.
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
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)
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.
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
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.
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.
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?
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?
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?
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?
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 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.
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.
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
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
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.