07:55 <fabiobassa> good morning roomies. Please need some opinions on running a linux server on rk3229 . I managed to have the board boot and fully funcional, but after EXACTLY 29 minutes and 59 the board freezes. How can I address the problem ?

07:57 <EmilKarlson> perhaps you could first try running initrd for just 30mins to exclude this thing is not triggered by userspace

08:00 <fabiobassa> good morning EmilKarlson ty for answer . I have several ROOTFS from diferent OS ( archlinux, linaro, devuan ) and all acting the same. Might I describe my environment to make the situation clear ?

08:03 <EmilKarlson> maybe, 30 mins seems very long for a kernel/hw timescale, someone could guess you have a watchdog of some sort

08:06 <fabiobassa> I wish to clarify that in the 30 minutes all is working perfectly ( NO hdmi but i want to use the board as server so no X needed) I run directly from internal NAND I have the same behaviour if i run " echo freeze /sys/power/state "

08:06 <fabiobassa> so definetly a freeze suspend hibernate problem but I don't know how to debug it

08:07 <EmilKarlson> are you really 2000% sure this is not userland?

08:08 <EmilKarlson> IdleAction=ignore

08:08 <EmilKarlson> #IdleActionSec=30min

08:08 <EmilKarlson> /etc/systemd/logind.conf

08:10 <EmilKarlson> in general your userland is expected to be pretty homogenic

08:11 <fabiobassa> EmilKarlson: and I also want to specify that I am notnoob noob but neither a programmer so if I say something weird just have patience lol ! I use devuan as my rootfs and devuan hasn't systemd but the old initrd and in any case it happens also with archlinux :linaro rootfs instead uses systemd so I can try to do what you suggest me

08:12 <EmilKarlson> I know, but devuan has to have certain amount of systemd compatibility

08:12 <fabiobassa> have you ever managed to have a full gnu-linux on internal nand of RK3229 ? this chip seems very difficult to manage

08:13 <fabiobassa> and also if I boot from SD all is working perfectly for how many hours I want so it must be some thing specific to board ( uboot left over ? misconfigured kernel ? I am going crazy to debug it )

08:15 <EmilKarlson> no, I have used the chromebooks exclusively

08:16 <EmilKarlson> internal nand should have nothing to do with this, but that is also trivial to check with the initrd thing

08:16 <fabiobassa> I have also try to compile using the chrome sources and of course adapting to 3229 dts , and again boot and hang after 30 min

08:17 <fabiobassa> ok so i should boot up to initrd and leave the system without userspace, right ?

08:17 <EmilKarlson> well just a shell

08:17 <fabiobassa> ok

08:18 <EmilKarlson> like /init is #!/bin/ash\nsleep 3600

08:19 <EmilKarlson> then link busybox that contains these applets to /bin and package as initrd

08:19 <EmilKarlson> or just ash as init

08:21 <fabiobassa> will try to do this. I did some " frankensten " cut/copy/paste " so I have original miniloader-all.bin, original u-boot.img, original trust.img and then MY boot.img ( with modified init of course ), My kernel , MY resources and My root fs .

08:24 <fabiobassa> EmilKarlson: but are you speaking of init ( init ram in few words) or the init after kernel started ( etc/init or /sbin/init ) ?

08:24 <EmilKarlson> I believe just /init

08:25 <fabiobassa> ok I will check this :)

08:25 <EmilKarlson> you can just try directly setting IdleAction=ignore on logind.conf

08:27 <fabiobassa> ok at least those are some good starting points . Ty so much and will give some feedsback

08:33 <fabiobassa> EmilKarlson: this is my actual /etc/Systemd/login https://pastebin.com/zp8jCqvw

08:34 <inode> fabiobassa: i still believe the problem is in some kind of initialization done by the original u-boot, rather than the mainline kernel

08:35 <inode> replace u-boot with mainline and this problem goes away

08:36 <inode> but i know that this doesn't help you because the board features NAND flash and not eMMC :)

08:37 <fabiobassa> hello justin good morning and nice to see you here ! How are you ? Really for my tests I am using 3.10.104 kernel and not the mainline that , as you teached me, hasn't support for internal nand ! Until u-boot mainline will not support rknand is a pity ,as we chatted many times.

08:37 <fabiobassa> inode: exactly no rknand on mainline

08:38 <inode> good thanks, and you? i got the mail btw, just had no time to respond

08:38 <fabiobassa> but i am really a step to have the board working as I desire and now this 30 minutes freeze is damning me

08:39 <fabiobassa> " just had no time to respond " is ok no worries :) . I will just follow suggestions from EmilKarlson and see what happen

08:41 <EmilKarlson> did you mean to uncomment that IdleAction=ignore

08:41 <EmilKarlson> as in, is it before or after a modification

08:41 <fabiobassa> I am doing it right now EmilKarlson i must ssh into board

08:42 <fabiobassa> original, before modification in pastebin

08:42 <EmilKarlson> inode: maybe, but why 30mins, watchdog would be only one I could think of and that's quite a slow dog for 1800 seconds

08:45 <inode> EmilKarlson: i'm not sure, and haven't had the motivation to figure out why, as i have personally experienced this problem on another rk3229 device when i replaced only the kernel and initrd - the problem has non-existent been non-existent since i've replaced the original bootloader with mainline u-boot

08:46 <EmilKarlson> inode: and you had the symptom of some exact timing?

08:46 <inode> and i also use a devuan rootfs, so essentially without systemd

08:46 <inode> yes correct

08:46 <inode> as 30 minutes is about to elapse the board locks up

08:49 <fabiobassa> inode: i tried as many rootfs you can image and the problem persist . but it happens also if i specificall run " echo freeze /sys/power/state" so maybe some cmdline from original uboot but is ever possible that in userspace no way to OVERRIDE the freeze suspend ? In any case EmilKarlson I modified systemd but now we must wait 30 minutes lol :)

08:50 <inode> some mentions i made of this issue while i was struggling: https://freenode.irclog.whitequark.org/linux-rockchip/2019-05-23

08:50 <inode> and https://freenode.irclog.whitequark.org/linux-rockchip/2019-05-28

08:57 <inode> the last mention was using mainline u-boot without OP-TEE, hence no PSCI and only cpu0 brought up

08:59 <inode> fabiobassa: regarding "but is ever possible that in userspace no way to OVERRIDE the freeze suspend ?" - maybe there is some kind of wakelock triggered from the original android initrd

09:01 <inode> or at least i'm guessing that the original initrd might lead you to the source of the problem as:

09:01 <inode> 11:44 <inode> my current problem is that after 30 minutes after boot, the device becomes unresponsive over ethernet, UART2 and tty0

09:01 <inode> 11:45 <inode> this also happens if i use the android kernel shipped with the device, but do not use the initrd that was intended for it

09:03 <fabiobassa> inode: me too , I thought also this eventuality so i was reading all the init.rc of original android ( init is compiled/executable but various rc are readable ) searching any reference to freeze or PSCI so I could replicate in new init

09:04 <fabiobassa> i used init from raxda rock :-)

09:05 <inode> how wide was your search string selection? :) wake|suspend|power|freeze|idle|... ?

09:06 <fabiobassa> it wasn't at all lol , I googled a lot for this problem and got some feedback of the same timing even on android OS , but i ner string in my rootfs

09:06 <fabiobassa> never*

09:08 <fabiobassa> I guess we cannot resume from sleeping because no touchscreen or no event from remote infrared

09:09 <fabiobassa> anyway my actual uptime is 09:08:58 up 26 min, 1 user, load average: 1.45, 1.49, 1.22 so in 4 minutes the sentence :-)

09:14 <fabiobassa> ok , board freezed even with IdleAction=ignore :(

11:29 <EmilKarlson> and you did uncomment it?

13:21 <fALSO> bom dia

14:42 <micken> lo

14:58 <micken> I am trying to bring my rk3288 videodriver to rk3399. Is there any difference in VOP?

15:16 <micken> OK have sync

15:16 <micken> now

15:16 <micken> but thanks anyway :D

18:37 <micken> Does anyone have a registerdescription or know how reg 0x14 in vop (rk3399) works?

18:39 <micken> I looked at running linux and figured that +20 bits needs to be set,, those are listed as reserverd in rk3288 docs

18:40 <micken> if I put something there I get sync, but I don't see my framebuffer

19:34 <mmind00> micken: 0x14 is "DSP_CTRL1" ... [23:20] are hdmi polarities

19:35 <micken> ok

19:35 <micken> mmind00: thanks

19:35 <micken> mmind00: is the other bits the same as rk3288?

19:36 <mmind00> micken: if you look into rockchip_vop_reg.c you can see it defined in "static const struct vop_output rk3399_output"

21:12 <micken> mmind00: thanks for the pointer,, however it is something else . I have the fc_dgb registers set and no colour on screen

21:12 <micken> fc_dbg

21:13 <micken> a bit odd, I followed rk3399 docs for hdmi when I did rk3288 :)

21:13 <micken> and i.mx6 docs

21:14 <micken> and I get sync now

21:14 <micken> the monitor reports wanted res