21 minutes ago, TonyMac32 said:

is that your direction moving forward?

I only adjust console with reality. I don't care where it will be, but it would be nice that we have it at one location on both kernels.

 

55 minutes ago, freak said:

Ok...  a co-worker with better eyes than me says I cut pin 15 on the hdmi cable not 13. 

 

Rather wait. You might go in the wrong direction. Work smart not fast. Try older bootloader first: http://apt.armbian.com/pool/main/l/linux-u-boot-tinkerboard-next/ This is the first and most cheap possible solution.

16 minutes ago, Igor said:

I only adjust console with reality. I don't care where it will be, but it would be nice that we have it at one location on both kernels.

 

 

Rather wait. You might go in the wrong direction. Work smart not fast. Try older bootloader first: http://apt.armbian.com/pool/main/l/linux-u-boot-tinkerboard-next/ This is the first and most cheap possible solution.

 

I think you misunderstand what I am saying.  I thought I cut line 13 which is CEC.  Turns out I cut line 15 which is DDC. 

48 minutes ago, freak said:

I think you misunderstand what I am saying.  I thought I cut line 13 which is CEC.  Turns out I cut line 15 which is DDC. 

no no, I'm quite sure @Igor understood exactly what you did. But first you thought you cut CEC and it seemed to help whereas in fact it was DDC. I adjusted the topic and everyone who read this thread thought current armbian might have a CEC issue...

And before you cut now all DDC wires you've to figure out what's going on... and what he suggests is to use older bootloaders cause it seems that your monitor avoids your boards from boot. Simplest would be use:

linux-u-boot-next-tinkerboard_5.38_armhf.deb       25-Jan-2018 10:33    448K

with an intact HDMI cable, revert uboot update from a updated board and see if this works. 

Maybe...  I just wanted to make sure.  Any tips or links for help on how to replace the bootloader?

 

edit - I figured it out.  Boots now.  What's the best course of action now?

13 hours ago, freak said:

What's the best course of action now?

1. check which u-boot version we had back then: https://github.com/armbian/build/blob/789909be3fb14234de76454964fcd4a214e28437/config/sources/rockchip.conf#L10-L12
2. maybe also which patches 
3. compare sources
4. figure out what differs and avoids a proper boot

have fun.  (a lot of debug)

Lol!  I'm going to load tinkeros and see if that works first.

56 minutes ago, freak said:

Lol!  I'm going to load tinkeros and see if that works first.

... and restart this saga when they eventually upgrade their u-boot. Lol!

Well you can't expect your end users to become u-boot hackers just to keep their systems running.  I realize you can't do everything for everyone and that's the dilemma that open source projects always face.

It was just a suggestion. If we want to get to the bottom of this, this is needed. 

 

You don't need to hack a u-boot if you already find the one that works. I assume you did find some older version that works? Than apply apt-halt on that package to prevent it's upgrading and you are done. Of course, this means you might suffer from other u-boot related problems ... Yes, it's complicated.

Hello. I have exactly the same problem on an HP EliteDisplay E242 display.

If I plug in the screen just after booting, the image is displayed correctly.

Edited November 9, 20187 yr by dragonlost

Although this may have been patched at some point (because the problem seems to have went away) it appears to be back again.