Jump to content

Recommended Posts

Posted

someone would have a tuto or info to add a custom configuration of the hdmi port to the tinkkerboard  (u-boot)  ?

hdmi_timings need for my screen : 1200 0 100 24 52 1920 0 65 4 25 0 0 0 60 0 169000000 0

Posted

The last time we enabled the HDMI in u-boot it crashed the kernel somehow. Never tried to debug it.

Sent from my Pixel using Tapatalk

Posted
12 hours ago, dragonlost said:

someone would have a tuto or info to add a custom configuration of the hdmi port to the tinkkerboard  (u-boot)  ?

hdmi_timings need for my screen : 1200 0 100 24 52 1920 0 65 4 25 0 0 0 60 0 169000000 0

You probably don't need to do that in u-boot. Did you try adding the modeline with cvt + xrandr? Here is a tutorial in this link

 

If that doesn't work, you can also try to add a line like the following to the file /boot/armbianEnv.txt (if it does not exist, then create it):

extraargs=video=HDMI-A-1:1920x1200@60

Of course, changing the resolution according to your needs.

Posted
19 hours ago, JMCC said:

You probably don't need to do that in u-boot. Did you try adding the modeline with cvt + xrandr? Here is a tutorial in this link

 

If that doesn't work, you can also try to add a line like the following to the file /boot/armbianEnv.txt (if it does not exist, then create it): 


extraargs=video=HDMI-A-1:1920x1200@60

Of course, changing the resolution according to your needs.

 

 

this screen work on my windows computer but in all my linux computer not work ( just rpi with config.txt). xrand and extraargs argument no have effect.

Posted
31 minutes ago, dragonlost said:

this screen work on my windows computer but in all my linux computer not work ( just rpi with config.txt). xrand and extraargs argument no have effect.

What do you put in config.txt in your rpì?

Posted

@TonyMac32 Probably I didn't explain my problem well.

 

When I run tinkerboard with armbian, I can NOT access the server through SSH or directly because HDMI doesn't work as well.

 

So I can't run the  armbianmonitor -u.

 

 

Posted

It's impossible to debug without information beyond "it doesn't work". As far as the no SSH issue, that is very irregular. What kernel/image/etc? I'm guessing you don't have the ability to watch the debug UART?

Sent from my Pixel using Tapatalk

Posted
1 hour ago, João Cravo said:

I can NOT access the server through SSH or directly because HDMI doesn't work as well.

I don't see the relationship between SSH and HDMI ...

 

Posted
3 hours ago, JMCC said:

What do you put in config.txt in your rpì?

 

on my raspberry :

hdmi_pixel_freq_limit=400000000
hdmi_drive=2
hdmi_mode=87
disable_overscan=1

# 10.1 inch
hdmi_timings=1200 0 100 24 52 1920 0 65 4 25 0 0 0 60 0 169000000 0
max_framebuffer_width=1920
max_framebuffer_height=1920
display_rotate=3
framebuffer_width=1920
framebuffer_height=1200

 

finally I was able to test my home on my linux is it worked. But still not on the tinkerboard.

On my linux computer :

"1200x1920_59.87"  159.00  1200 1215 1216 1320  1920 1983 1985 2012  +HSync +VSync

I have to test this xrandr parameter in my tinkerboard.

 

 

Posted

@martinayotte It's two different problems, of course.
1- I can't connect to port 22 (although ping works, so I have routing to the board).
2- I can't get any image on a monitor over HDMI. 
 

@TonyMac32 You are completely right. I know for you it's very difficult to help me with me just complaining "it doesn't work".
I hoped that someone here had a similar problem in the past and point me that I'm doing some kind of "rookie" mistake.

 

The armbian version I'm using was Armbian_5.35.171201_Tinkerboard_Ubuntu_xenial_next_4.14.2 and similar desktop version. I tried more 1 or 2 older versions  from https://dl.armbian.com/tinkerboard/archive/ without success. 

I would say the problem was on my board but I got it working with tinkerOS (both ssh and HDMI)
So the problem is somewhere else... 

Posted
22 minutes ago, João Cravo said:

1- I can't connect to port 22 (although ping works, so I have routing to the board).

I've seen a case where file system was corrupted, SSL certificate/keys file corrupted preventing the SSHD to start.

That could explain your issue ... To be sure, you need to log using USB-TTL Serial dongle and verify the log, especially "systemctl status ssh.service".

 

Posted

If the 4.14 image is from the right period of time, the u-boot can lock up while trying to init the HDMI monitor. That's what I mentioned to dragonlost earlier.

Sent from my Pixel using Tapatalk

Posted
21 hours ago, TonyMac32 said:

can lock up while trying to init the HDMI monitor

Was this where you had to unplug and plug again?

Posted

This was where you boot without the monitor attached and plug it in later. But that was only a few reports, best to just use an up to date image

Sent from my Pixel using Tapatalk

Posted

I just tested the following ones
- Armbian_5.75_Tinkerboard_Debian_stretch_next_4.19.20
- Armbian_5.75_Tinkerboard_Ubuntu_bionic_next_4.19.20
- Armbian_5.75_Tinkerboard_Ubuntu_bionic_next_4.19.20_desktop

Always the same result as showed below :( 
I guess I will buy the USB-TTL Serial dongle and give it a try as @martinayotte suggested.

$ sudo nmap -sn 192.168.0.0/24
Starting Nmap 7.70 ( https://nmap.org ) at 2019-03-03 13:21 CET
Nmap scan report for tinkerboard.home (192.168.0.10)
Host is up (0.015s latency).
MAC Address: 88:D7:F6:C2:E3:ED (Asustek Computer)
(...)

$ ping 192.168.0.10
PING 192.168.0.10 (192.168.0.10): 56 data bytes
64 bytes from 192.168.0.10: icmp_seq=0 ttl=64 time=3.717 ms
64 bytes from 192.168.0.10: icmp_seq=1 ttl=64 time=4.386 ms
64 bytes from 192.168.0.10: icmp_seq=2 ttl=64 time=5.429 ms

$ nc -v 192.168.0.10 22
nc: connectx to 192.168.0.10 port 22 (tcp) failed: Operation timed out

 

Posted

What I sometimes do before I resort to the serial port:

 

If you are starting from sd-card, take it and insert it with a USB adapter on a linux pc. Mount it and look at /var/log to get some hints.

 

Perhaps put some diagnostic commands into /etc/rc.local, like "systemctl status ssh.service (with output into a file)" or whatever (like netstat -tlpen, is port even open?). Especially perhaps try to run "armbianmonitor -u" in there.

 

Reboot, and then take it to a pc again and look at the output.

 

It's a pain but sometimes you can see something while you are waiting for the USB-TTL serial dongle.

 

Posted
3 hours ago, João Cravo said:

I just tested the following ones
- Armbian_5.75_Tinkerboard_Debian_stretch_next_4.19.20
- Armbian_5.75_Tinkerboard_Ubuntu_bionic_next_4.19.20
- Armbian_5.75_Tinkerboard_Ubuntu_bionic_next_4.19.20_desktop

Why don't you test some "Default" images (kernel 4.4.y)? If those work, then at least we can narrow down the problem to mainline.

Posted

@suberimakuri:

 

 ____                                 _
|  _ \ ___ _ __   ___  __ _  __ _  __| | ___
| |_) / _ \ '_ \ / _ \/ _` |/ _` |/ _` |/ _ \
|  _ <  __/ | | |  __/ (_| | (_| | (_| |  __/
|_| \_\___|_| |_|\___|\__, |\__,_|\__,_|\___|
                      |___/

Welcome to ARMBIAN 5.76 user-built Ubuntu 18.04.2 LTS 4.20.13-rockchip64
System load:   0.02 0.17 0.11   Up time:       8 min
Memory usage:  14 % of 1998MB   IP:            10.0.0.47
CPU temp:      48°C
Usage of /:    12% of 15G

[ General system configuration (beta): armbian-config ]

So that works, although missing a USB port (bottom USB2 is not with us).

Posted

@jpegxguy  For the mainline ethernet tx/rx delays, were those just copied from the Rock64 or were they empirically determined?  They're caused by trace impedance/etc, so they're tied to the specific hardware.  I'll dig up the thread/tool Ayufan and Tkaiser were using and see what I get, there might be some more to gain there, since obviously the default ones are fairly bad.

 

@Igor Any argument against moving Ayufan's RK3328 mainline to "next" and putting true mainline at "dev"?  I think it's to the point that 5.1/5.2 are nearly to RK3288 levels of support in mainline.

 

[edit]  Fixed the lower USB port on Renegade.

Posted
10 hours ago, TonyMac32 said:

@jpegxguy  For the mainline ethernet tx/rx delays, were those just copied from the Rock64 or were they empirically determined?  They're caused by trace impedance/etc, so they're tied to the specific hardware.  I'll dig up the thread/tool Ayufan and Tkaiser were using and see what I get, there might be some more to gain there, since obviously the default ones are fairly bad.

 

@Igor Any argument against moving Ayufan's RK3328 mainline to "next" and putting true mainline at "dev"?  I think it's to the point that 5.1/5.2 are nearly to RK3288 levels of support in mainline.

 

[edit]  Fixed the lower USB port on Renegade.

It would be very cool if you did! I have no objection to that kernel arrangement either

Posted

I don't use an sd card, but I did try with mmc0 too. It seems to work for me, K 4.20 and 5.0 from archlinuxARM. The gpio-controller thing seems to be there in upstream as well

Posted

On another note, if the 8ma changes for SD card that are in armbian sources aren't upstream and you consider them better, definitely do send patch upstream! Good work

Posted

Right, I'm getting a statement that the gpios on the rk805 don't exist from the driver, see debugging is in order there if I have time.  The Rock64 patches look the same, I'll test that when I can. 

 

For the drive level, I'm hoping to capture the waveforms with my oscilloscope to demonstrate the differences beyond theory and some rectified boot failures, then I'll set them up as overrides in the individual dts's as Robin rightly pointed out on a similar topic that the increased drive level will cause increased EMI from the board, some users won't be fan. 

Posted

Hello.

After a lot of trying with xrandr. I can not have an image on the tinkerboard with this screen.

Here is the edid of the screen.
 

connected 1920x1200+0+0 (0xd4) right (normal left inverted right x axis y axis) 720mm x 720mm
    Identifier: 0x6a
    Timestamp:  245757
    Subpixel:   unknown
    Gamma:      1.0:1.0:1.0
    Brightness: 1.0
    Clones:    
    CRTC:       2
    CRTCs:      0 1 2
    Transform:  1.000000 0.000000 0.000000
                0.000000 1.000000 0.000000
                0.000000 0.000000 1.000000
               filter:
    EDID:
        00ffffffffffff00328d5e04aac83301
        241b0103951f1178eaebf59559549027
        1e505400000001010101010101010101
        0101010101011c3eb07840805c700f01
        f20cd0d02200001e0000000000000000
        00000000000000000000000000fe004c
        6f6e7469756d0a2020202020000000fe
        00776972656c6573732d7461670a01be
        02031902000000000000002308070783
        00000065030c00100000000000000000
        000000000000000000001e0000000000
        00000000000000000000000018000000
        00000000000000000000000000001800
        00000000000000000000000000000000
        18000000000000000000000000000000
        0000000000000000000000000000003a
    non-desktop: 0
        range: (0, 1)
    link-status: Good
        supported: Good, Bad
  1200x1920 (0xd4) 159.000MHz +HSync +VSync *current +preferred
        h: width  1200 start 1215 end 1216 total 1320 skew    0 clock 120.45KHz
        v: height 1920 start 1983 end 1985 total 2012           clock  59.87Hz


I tried to start with to see. Then to see with ssh or vnc or nomachine. Can not see the screen.

 

Posted
2 hours ago, dragonlost said:

I can not have an image on the tinkerboard with this screen.

Did you try the Default (4.4.y) kernel?

Posted
On 3/4/2019 at 4:35 PM, TonyMac32 said:

@jpegxguy

@Igor Any argument against moving Ayufan's RK3328 mainline to "next" and putting true mainline at "dev"?  I think it's to the point that 5.1/5.2 are nearly to RK3288 levels of support in mainline.

 

[edit]  Fixed the lower USB port on Renegade.

 

On last look Ayufan stripped all the modules out after 4.4 which ran Ubuntu plus rock ones.

 

I've got a v3 on the way and can do some testing of 5.x.

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

Important Information

Terms of Use - Privacy Policy - Guidelines