Jump to content

HDMI-Monitor bricked tinkers today (next 5.60)

freak

By freak
in Tinkerboard

 Share

Recommended Posts

Igor

Igor

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

so, enough off topic here... 

Expand  


We were off topic all the time so I did change the name of it. 
 

  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  


Regressions happen and will happen in the future.


https://www.google.com/search?q=how+many+people+work+on+the+kernel

"There are over 13,500 developers working on the Linux kernel, most of them will know the general workings of the kernel. No one knows the exact details of what every line of code does in the monster kernel. Even Linus Torvalds himself does not know every detail of the kernel, it's not the pet project he started in 1991 anymore"

 

There are tens of thousands of Tinkerboard users and since it only bricked a few of your boards (a problem with some of your monitors, cablings, DVI adaptors), the issue is not critical. That changes a view on the problem for 360. If you want us or me to solve your problem, its possible, but our resources are so tiny that waiting time is currently measured in years. If donations bump for 100x, I will hire a few professionals to help out. Until we have to earn money elsewhere to keep this project running ... this remains as is.

 

There are many kernel hackers out there who are fixing problems for money. You can also just switch faulty hardware. It's your call.

freak

freak

Posted
  • Author
Posted
  On 9/26/2018 at 5:15 AM, Igor said:

There are many kernel hackers out there who are fixing problems for money. You can also just switch faulty hardware. It's your call.

Expand  

 

I'll ship you a brand new http://a.co/d/2YbJdo1 and if it turns out to not be a software problem you can keep it.  Deal?

Igor

Igor

Posted
Posted
  On 9/26/2018 at 12:38 PM, freak said:

PM me a shipping address.

Expand  


I personally don't need it and have no time - it will be donated directly to one of the project volunteers (living in US or Canada). Will send you info ASAP. Thanks.

freak

freak

Posted
  • Author
Posted

Another update...  Fresh install of Bionic...  Won't boot with monitor plugged in.

 

Remove power, Unplug hdmi, replace power, allow time to boot, plug hdmi, system is up and running.

 

(yes I'm still working on getting you logs Igor but I'll be out of town for the next few days)

freak

freak

Posted
  • Author
Posted

By update I meant and update to the thread not to the system.  That was using a fresh install of bionic from the download page.

TonyMac32

TonyMac32

Posted
Posted

By update I meant whatever change you have done.  I am generally uninterested in this thread other than a potential bug that can keep the board from booting.  My query is because it is possible (although unlikely, since 4.14 has some crust developing on it) that @Myy may have an idea what's going on without putting too much time into it.   

freak

freak

Posted
  • Author
Posted

update again...  I connected two tinkers...   Installed picocom.    Using fresh install of armbian 5.59 4.14.67 I can watch the tinker in question boot just fine over the tty... IF the hdmi cable is not plugged in.  With HDMI plugged in it will not boot at all.  The boot is not visible through the tty because it's not booting so I cannot get logs.

 

Next...

 

Using fresh install of armbian 5.41 4.14.23 on exact same tinker and monitor and cable and power supply, the system boots fine.  HOWEVER, if I take this fresh install of 5.41 4.14.23 and run apt update/upgrade the system no longer boots unless you remove the HDMI cable (just like above using 5.59 4.14.67).  And as it doesn't even attempt to boot there are no logs to be had.  Not sure what to try next.

 

 

chwe

chwe

Posted
Posted
  On 9/26/2018 at 3:13 PM, freak said:

The startup is not visible through the tty so I cannot get logs.

 

Expand  

sure? where did you connect it? UART2 or UART3? for new images it should definitively be UART3 and from the 'console video' I made (https://asciinema.org/a/IJhwnKjfp0fyOmeZyKKccHKW5) you should get some sort a bootlog. Obviously the console must be started before you power the second board.. otherwise you'll be to late.. :) It's possible that we hat UART2 during 5.41 (can't remember anymore) so it might be not as easy to monitor this update if it switches the console during update.. (well you could monitor both uarts in two consoles :P)

freak

freak

Posted
  • Author
Posted

Here's a cool update...  I took an extra hdmi cable I had lying around and cut what I believe to be the CEC line and the system boots fine.

Myy

Myy

Posted
Posted

Logging through the serial console is configured through systemd and boot parameters... But, yeah, one of the default behaviour is to output the kernel messages through the serial console ONLY IF no screen is available.

 

So I guess that HDMI CEC support is broken ? Does the freeze happen with other screens too ?

 

The default UART for debugging purposes on RK3288 is the UART2 (/dev/ttyS1). It might be changed though. The RK3288 Datasheet name UART2 "uart2dbg". UART3 is for plugging GPS systems (which is not used very often, I concur).

 

Just for information :

1. When the HDMI cable is plugged, do you have any SSH access ? If you wait for 5 minutes, is it still frozen ?

2. If you start without an HDMI cable, get a serial console and *then* plug the HDMI screen, what happens ? Do you have any crash or freeze message ?

 

I remember some bug a long time ago, about 4.14 kernels... That would make the system unbootable if you plugged the HDMI cable before booting :

https://github.com/Miouyouyou/RockMyy-Build/issues/1

I don't remember how I was able to get a log for this though...

TonyMac32

TonyMac32

Posted
Posted
  On 9/26/2018 at 4:17 PM, Myy said:

The default UART for debugging purposes on RK3288 is the UART2 (/dev/ttyS1). It might be changed though. The RK3288 Datasheet name UART2 "uart2dbg". UART3 is for plugging GPS systems (which is not used very often, I concur).

Expand  

Yes, but the Tinker moves it from 2 to 3 to keep common with what ASUS is doing.  I think the UART 2 might be blocking an IO range that periogerals could use, but pure speculation.  

 

 

1
freak

freak

Posted
  • Author
Posted
  On 9/26/2018 at 4:17 PM, Myy said:

Logging through the serial console is configured through systemd and boot parameters... But, yeah, one of the default behaviour is to output the kernel messages through the serial console ONLY IF no screen is available.

 

So I guess that HDMI CEC support is broken ? Does the freeze happen with other screens too ?

 

The default UART for debugging purposes on RK3288 is the UART2 (/dev/ttyS1). It might be changed though. The RK3288 Datasheet name UART2 "uart2dbg". UART3 is for plugging GPS systems (which is not used very often, I concur).

 

Just for information :

1. When the HDMI cable is plugged, do you have any SSH access ? If you wait for 5 minutes, is it still frozen ?

2. If you start without an HDMI cable, get a serial console and *then* plug the HDMI screen, what happens ? Do you have any crash or freeze message ?

 

I remember some bug a long time ago, about 4.14 kernels... That would make the system unbootable if you plugged the HDMI cable before booting :

https://github.com/Miouyouyou/RockMyy-Build/issues/1

I don't remember how I was able to get a log for this though...

Expand  

1. No ssh access.  Left it sit for an hour or more.

2. My guess is it works but I just messed up my test environment.  I'll have to redo everything next week.  Today's my last day till Monday.

freak

freak

Posted
  • Author
Posted

...in the meantime I'm going to walk around with cutters and clip the red wire on all my terminals.  Lol!

 

freak

freak

Posted
  • Author
Posted

Does anyone know why kernel options don't save in armbian-config?  I've set hdmi_ignore_cec=1 but changes always disappear upon reboot.  Not that I know that would fix it but there's a number of hdmi options I thought I would try.

TonyMac32

TonyMac32

Posted
Posted

Well, it's a clean 4.14 from kernel.org with patches that can be found in our build system. If CEC is killing it, then that driver could be blacklisted. Out of curiosity, can you give me the output of armbianmonitor -u on a board you start without the monitor plugged in, and of one with a cut wire?

Sent from my Pixel using Tapatalk

  • chwe changed the title to HDMI-Monitor with CEC bricked tinkers today (next 5.60)
  • chwe pinned this topic
freak

freak

Posted
  • Author
Posted

uname -a
Linux tinkerboard 4.14.23-rockchip #55 SMP PREEMPT Thu Mar 1 10:56:06 CET 2018 armv7l armv7l armv7l GNU/Linux
 

armbian 5.41 4.14.23 as downloaded.  No upates - plugged in to monitor - CEC wire connected...

http://ix.io/1o15

 

armbian 5.41 4.14.23 as downloaded.  No upates - NOT plugged in to monitor - CEC wire connected...

http://ix.io/1o17

 

armbian 5.41 4.14.23 as downloaded.  No upates - plugged in to monitor - CEC wire DISconnected...

http://ix.io/1o19

 

 

armbian 5.41 4.14.23 as downloaded.  apt upgrade finished - plugged in to monitor - CEC wire connected...

(no boot cannot provide logs)

 

uname -a
Linux tinkerboard 4.14.70-rockchip #270 SMP PREEMPT Wed Sep 19 11:40:40 CEST 2018 armv7l armv7l armv7l GNU/Linux


armbian 5.41 4.14.23 as downloaded (4.14.70 now).  apt upgrade finished - plugged in to monitor - CEC wire DISconnected...

http://ix.io/1o1j


armbian 5.41 4.14.23 as downloaded (4.14.70 now).  apt upgrade finished - monitor plugged in AFTER boot - CEC wire connected

http://ix.io/1o1l

 

armbian 5.41 4.14.23 as downloaded (4.14.70 now).  apt upgrade finished - monitor plugged in AFTER boot - CEC wire DISconnected

http://ix.io/1o1m

 

(testing finished)

 

I should note that with the CEC wire disconnected only two resolutions are available - 800x600 and 1024x768.

With CEC connected and monitor plugged after boot I can get up to 1920x1080 (even though the monitor supports up to 1920x1200.

 

 

 

freak

freak

Posted
  • Author
Posted

Ok I switched to ttyS2 instead of ttyS3 and I get this at boot with CEC connected... (via picocom)

  

U-Boot 2018.07-armbian (Sep 19 2018 - 13:23:29 +0200)

Model: Tinker-RK3288
DRAM:  2 GiB
MMC:   dwmmc@ff0c0000: 1, dwmmc@ff0f0000: 0
Loading Environment from EXT4... Card did not respond to voltage select!
** Bad device mmc 0 **
Failed (-5)

 

...and it just stops there.

freak

freak

Posted
  • Author
Posted (edited)

Here's the full boot with CEC disconnected...

  Reveal hidden contents

 

Edited by Tido
tooo long, added spoiler for comfortable thread reading
freak

freak

Posted
  • Author
Posted

Ok...  a co-worker with better eyes than me says I cut pin 15 on the hdmi cable not 13.  If that's right that's DDC?  Not sure what the implications are of that.  I ordered an hdmi cable tester which should be here tomorrow.

TonyMac32

TonyMac32

Posted
Posted

Well, U-boot appears to be the issue, at least initially. That's at least something.
@Igor, the tty for Tinker OS was moved to 3, I thought I had u-boot and kernel set to that, however in all the mess it could have been mixed. I saw your commit to move back to 2, is that your direction moving forward?

Sent from my Pixel using Tapatalk

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

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept