Jump to content

RK3328 Kernel


Peba

Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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ì?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

 

 

Link to comment
Share on other sites

@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... 

Link to comment
Share on other sites

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".

 

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@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).

Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines