SystemLED *ON* on boot

[ecolezen]

Hi, just want to share a little tip:
How to turn the systemLED ("LED") to *ON* when the board is booting (loading the system).



My 1GB Pine64 Board sometimes start booting process and sometimes don't... so I have to way and "see" activities on the screen or LAN interface...

So, I decided to put an LED on the systemLED holes (label "LED"), and switch it to ON when booting...



When using without a monitor (remote) this LED is very helpful...

These 3 lines of script turn the LED to "ON":

Code:

echo "359" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio359/direction
echo "0"   > /sys/class/gpio/gpio359/value

Full instructions on the link below:
http://www13.plala.or.jp/pskitty/pine64-sysled.html

Drawings, source code, high quality photo, etc, on GitHub:
https://github.com/valterfukuoka/pine64-sysled

Regards all,
Valter

[MarkHaysHarris777]

Very good;

... now take it one step further. When you turn the sysled ON you know it got to a certain point in the boot process (this is good) but you can expand that with light patterns (similar to shore line strobes) that tell you other things about the system based on the pattern and the timing.  For instance, on my Pine64+ boards my sysled ( which I cable to the front of the ABS case which holds the board ) a slow 'heart beat' pattern indicates that the system is up, and idle.

See this link:



( moved thread to gpio )

[ecolezen]

Very good;

... now take it one step further. When you turn the sysled ON you know it got to a certain point in the boot process (this is good) but you can expand that with light patterns (similar to shore line strobes) that tell you other things about the system based on the pattern and the timing.  For instance, on my Pine64+ boards my sysled ( which I cable to the front of the ABS case which holds the board ) a slow 'heart beat' pattern indicates that the system is up, and idle.

See this link:



( moved thread to gpio )

Hi, yes I am thinking about using the sysLED to signal more than just on/off... still thinking what should try next...

Because my board does not come "on" every time, this was the first thing/think that occour to me to provide some little help...

My next move is to have a small MCU to *watch* this LED (pin) and, when it DOES NOT come to "on" after a certain amount of time, the MCU will issue a hardware reset (physical), wait again and issue reset(s) until the board really enters in boot process... well, at least this is what I am thinking (not tried yet) since I want to use this little board, besides having this boot issue...
Not a good solution but, as long as it works, will "resolve" the issue with boot, for me...

regards,
Valter

[pfeerick]

Hi, yes I am thinking about using the sysLED to signal more than just on/off... still thinking what should try next...

This might give you some ideas... I just link to this in rc.local at boot... although you could also use a @reboot cron trigger.

https://github.com/pfeerick/pine64-scrip...artbeat.sh

Using a MCU to act as a hardware 'watchdog' sounds like fun... please keep us updated on how you go! I've thought about doing the same myself, but the few times my pine64s get rebooted and play up on boot I just cycle them a few times until they take the hint. I have about dozen 8 leg PICs and ATTinys knocking around that could do the job quite nicely... it might go back onto the long list of things to do!

[ecolezen]

This might give you some ideas... I just link to this in rc.local at boot... although you could also use a @reboot cron trigger.

https://github.com/pfeerick/pine64-scrip...artbeat.sh

Using a MCU to act as a hardware 'watchdog' sounds like fun... please keep us updated on how you go!    I've thought about doing the same myself, but the few times my pine64s get rebooted and play up on boot I just cycle them a few times until they take the hint. I have about dozen 8 leg PICs and ATTinys knocking around that could do the job quite nicely... it might go back onto the long list of things to do!

Hi, thanks for the link, perhaps the little trouble will end up giving us a nice way to explore this sysled stuff..

[MCU]
As soon as I put the first proto working I will post some results and thinking about, if works at least at satisfactory level I will build a little tuto.. also I will acquire more boards (units)...


To be honest, I was expecting to have a better idea about the behavior of the problem... but after some tests and reading online, I still not sure what is the issue itself... my only vague candidate to acuse is, maybe, something conected with the power lines that flows to the SDCard causing the first stage of the bootloading process to freeze...


Of course, the above statement about the SDCard power is my only-vague-candidate for a pattern of behavior to the problem that my unit have... also, I have not done any kind of deep analisys of the problem, so, I am just writing my "first impression" on the subject based on the few data that I have...

So, since the thing is crazy, I think that a little dirt brute-force method can work for me, since I am seeing a good promise on this little board, and I want to use it headless-remote...

So, in a sense, I just want to find ANY solution to the problem, even if we can't state clear what the problem we are solving (which is something strange to say)...

I have/had higher expectations for this board, thinking about the possibility to use it as part of a product/service, but, this part of the thinking is now gone... still, for my own use, I think this SBC is just fine and nice... as long as it can boot...

Regards,
Valter