Jump to content

Recommended Posts

Posted

I have 85 tinkers running with armbian 5.41 xenial next 4.14.23.  Normally I run a script that apt upgrades them all but I run a small batch of them first as a test.  Today I ran apt update/upgrade on three of them and they are all bricked.  No output to the screen.  Can't ping them.  Any ideas?

Posted
  On 9/25/2018 at 3:31 PM, freak said:

I have 85 tinkers running with armbian 5.41 xenial next 4.14.23.  Normally I run a script that apt upgrades them all but I run a small batch of them first as a test.  Today I ran apt update/upgrade on three of them and they are all bricked.  No output to the screen.  Can't ping them.  Any ideas?

Expand  


We need to see serial console logs.

Posted
  On 9/25/2018 at 3:57 PM, freak said:

TTL is ok on those pins?

Expand  


Yes, but you don't need to do anything. I already found the cause of the problem. Just do a power cycle.

Posted

I did try to replicate and start with some ancient build (older than yours, 5.33) than making an upgrade. It stalled at reboot ... cutting power and powering back resolved the problem and board is alive. 

Those are my logs: http://ix.io/1nwv

Serial console log:
 

  Reveal hidden contents
 

 

Posted

Now you need to get logs. From our perspective, everything works. Have you perhaps update to Bionic?

Posted
  On 9/25/2018 at 4:15 PM, freak said:

Power cycling isn't solving it.

Expand  

well then set up serial console.. and provide some bootlog.

 

I noticed that reboot after update of my tinker from 5.5x (don't remember exactly) to 5.60 took a way longer than normal. Maybe I should stick a serial console to it to get a clue why.. But if I remember correctly I didn't had to power-cycle it.. 

Posted

I don't have the usb/ttl adapter but I'll order one.  In the meantime I don't mind upgrading to bionic.  Can I do it from the command line from the build that I'm at?

Posted
  On 9/25/2018 at 4:34 PM, freak said:

I don't have the usb/ttl adapter but I'll order one. 

Expand  


It's an amazing tool for the value :) It can save you a lot of time and money. 

 

  On 9/25/2018 at 4:34 PM, freak said:

In the meantime I don't mind upgrading to bionic. 

Expand  


That was more as a rhetorical question. Upgrade to Bionic might cause troubles but if you start with a clean image, you should be fine. That upgrade is out of our power to help you in case of troubles. 

Posted

 

  On 9/25/2018 at 5:27 PM, freak said:

Is whatever what was wrong fixed so I can run apt upgrade with bricking the rest of the units?

Expand  


No!

We didn't find nor fix any problems. You have to get a serial console and show us what do you see when you power the bricked device. Perhaps the problem is in your configuration which is not our problem. I have no idea without seeing logs.

Posted

or... you SSH into a working SBC and use it's spare UART pins to ttl into the non-working SBC... :lol:

Likely to be one of the most silly things I've ever did with an SBC.. But hey, it works... :lol: (at least @martinayotte will like it. :ph34r: :P )

 

DSC_1115.png.034c5ca44927425c69044e1b0b703be2.png

 

B87EOGhc0gx9oikMAGEG94lXR.png

 

 

  On 9/25/2018 at 3:49 PM, Igor said:

Pins:
tinkeruart.png

Expand  

do we have UART2 and UART3? at least on mine (4.14) we use UART3...  @TonyMac32? Or was it back then when we used UART2? Can't remember anymore.. :P 

Posted

...and I can re-image the affected boards to fix them.  But for the working ones I'd like to upgrade to bionic if I can do that via the command line.

Posted
  On 9/25/2018 at 5:33 PM, chwe said:

do we have UART2 and UART3? at least on mine (4.14) we use UART3... 

Expand  


This picture was taken on a working UART with kernel 4.14.y 

 

  On 9/25/2018 at 5:36 PM, freak said:

I'd like to upgrade to bionic if I can do that via the command line.

Expand  


Do (ask google), but in case of troubles don't cry :) You have been warned.

Posted

I'm at work so I can't check, but we should match the vendor, which is the UART at the bottom of the gpio header.

 

REMEMBER 3.3V I/O

 

Sent from my Pixel using Tapatalk

 

 

 

 

Posted
  On 9/25/2018 at 5:39 PM, Igor said:
  On 9/25/2018 at 5:33 PM, chwe said:

do we have UART2 and UART3? at least on mine (4.14) we use UART3... 

Expand  


This picture was taken on a working UART with kernel 4.14.y 

Expand  

mine too.. :P See photo and that's UART3:

  On 9/25/2018 at 5:33 PM, chwe said:

DSC_1115.png.034c5ca44927425c69044e1b0b703be2.png

Expand  

 

even reboot works with ssh (notebook) --> ttl (OPi0) --> tinkerboard

:lol:

 

IJhwnKjfp0fyOmeZyKKccHKW5.png

 

Posted
  On 9/25/2018 at 5:44 PM, freak said:

Why "do-release-upgrade -d"?  Isn't there a stable release?

Expand  


Google's first hit: https://linuxconfig.org/how-to-upgrade-to-ubuntu-18-04-lts-bionic-beaver

 

Even Canonical recommends running distribution upgrade (old stable -> stable) from a serial console ... which you don't have. Anyway, we are getting off topic and out of free support for which you need to supply UART data. Now @chwe supplied alternative and working option.

Posted

Update:   This may have something to do with the resolution.  These a mostly connected to 1920x1200 HP monitors often with hdmi to dvi cables (sometimes hdmi both ends) but quite often they only run at 1920x1080.  But they work.  This "bricked" unit boots fine when connected to a acer G215H 1920x1080 monitor via hdmi/dvi.  Connected to an HP z27N via straight hdmi it will not boot.

Posted
  On 9/25/2018 at 5:56 PM, freak said:

Update:   This may have something to do with the resolution.  These a mostly connected to 1920x1200 HP monitors often with hdmi to dvi cables (sometimes hdmi both ends) but quite often they only run at 1920x1080.  But they work.  This "bricked" unit boots fine when connected to a acer G215H 1920x1080 monitor via hdmi/dvi.  Connected to an HP z27N via straight hdmi it will not boot.

Expand  

 

I was waiting for this. A prove that there is nothing wrong with our work. Thank you!
 

Armbian does not provide support for 3rd party hardware, which are the root of this problem -> a few people can't provide FREE support for all kind of electronic junk on this planet in their spare time. I hope you do understand this?

Without logs, problems are not even officially recognized. That's why I repeat myself like a parrot. Only logs might tell if we can solve the problem quickly or we will just file it. 

Posted
  On 9/25/2018 at 6:22 PM, Igor said:

 

I was waiting for this. A prove that there is nothing wrong with our work. Thank you!
 

Armbian does not provide support for 3rd party hardware, which are the root of this problem -> a few people can't provide FREE support for all kind of electronic junk on this planet in their spare time. I hope you do understand this?

Without logs, problems are not even officially recognized. That's why I repeat myself like a parrot. Only logs might tell if we can solve the problem quickly or we will just file it. 

Expand  

 

But to be fair... all 85 of my boards were working fine till I ran apt upgrade.

Posted
  On 9/25/2018 at 6:53 PM, freak said:

But to be fair... all 85 of my boards were working fine till I ran apt upgrade.

Expand  

we don't willingly break hardware support just to upset someone... :lol: If it happens it's likely out of our control.. (e.g. kernel) and it's simply not possible to first: avoid all those possible scenarios of third party hardware and second provide you some help without even knowing what's going wrong. 

  On 9/25/2018 at 5:56 PM, freak said:

This "bricked" unit boots fine when connected to a acer G215H 1920x1080 monitor via hdmi/dvi. 

Expand  

means bricked here upgraded power-cycled and then rebooted or with a freshly installed armbian? 

 

  On 9/25/2018 at 3:31 PM, freak said:

5.41 xenial next 4.14.23.

Expand  

from the changelog:

v5.41 / 10.2.2018

fixed LED driver on Helios4
bugfix update on sunxi/sunxi64 kernel. Updated to 4.14.18
kernel update for MVEBU next (4.14.18 and default 4.4.115) for Clearfog and Helios4. Upstream fixes,AUFS and Realtek 881yAU drivers update

that's 8 months without doing any updates? Have fun to figure out when and which changes ended in 'doesn't work anymore'.  IMO simply not possible.  But

git@tinkerboard:~$ find /dev | grep ttyS
/dev/ttyS3
/dev/ttyS2
/dev/ttyS1
/dev/ttyS0

serial access is possible... 

You can even build circles.. :lol:

IMG_20180925_214716.thumb.JPG.a1ed82ba6a68c82828c3ca965fd4a658.JPG 

SSH --> (opi) ttl --> (tinker) ttl --> opi :lol:

 

bII8nLIfmUnGHXKaylIqoLzXW.png

 

with 85 tinkers, there should be one spare to debug one which is 'bricked' due to upgrade... Just connect UART1 to another boards UART3 (that's the one you want to debug) install picocom on the first one and then:

picocom -b 115200 -r -l /dev/ttyS1

 

  On 9/25/2018 at 6:37 PM, martinayotte said:

:D

Expand  
  On 9/25/2018 at 5:33 PM, chwe said:

one of the most silly things I've ever did with an SBC.. But hey, it works... :lol: (at least @martinayotte will like it. :ph34r: :P )

 

Expand  

well.. obviously not true anymore.. :D 

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines