cp- has quit [Quit: Disappeared in a puff of smoke]
cp- has joined #linux-rockchip
adjtm has joined #linux-rockchip
matthias_bgg_ has quit [Ping timeout: 245 seconds]
TomTheDragon has joined #linux-rockchip
<TomTheDragon>
I'm having an issue with an MXQ 4k box (rk3229) which I've managed to get to boot, video/mouse/keyboard and all... but it comes down exactly 30 seconds after starting up.
<TomTheDragon>
Various people have been having this issue for years... but I can't track down a resolution.
field^Mop has joined #linux-rockchip
yann|work has quit [Ping timeout: 245 seconds]
<TomTheDragon>
sysfs seems to show a watchdog device, but it's status is "disabled"
vagrantc has joined #linux-rockchip
drrty has quit [Remote host closed the connection]
drrty has joined #linux-rockchip
stikonas has joined #linux-rockchip
warpme_ has quit [Quit: warpme_]
vicencb has quit [Ping timeout: 245 seconds]
vagrantc has quit [Quit: leaving]
adjtm has quit [Ping timeout: 276 seconds]
warpme_ has joined #linux-rockchip
vicencb has joined #linux-rockchip
warpme_ has quit [Quit: warpme_]
<inode>
TomTheDragon: if you're happy to boot from an sd card instead of the nand flash... you can compile optee, uboot and linux and you won't have that issue any more - unfortunately mainline uboot nor mainline linux feature a driver suitable for rockchip's nand controller
<TomTheDragon>
inode: I'm not really interested in booting from the nand flash to be honest... or rather, I don't care too much about having to.
<TomTheDragon>
inode: I'm actually experiencing this issue running a Debian image
<TomTheDragon>
That looked interesting, but I got a system bootup just by running the debian image for respeaker box. it's just crashing... but it seems senseless, since it's Linux, not Android.
<TomTheDragon>
inode: what actual machine is this
<inode>
TomTheDragon: what do you mean?
<TomTheDragon>
inode: I mean I'm not running from the Android kernel, which is what typically causes that issue, I thought
<inode>
my initial guess would be a lack of rockchip watch dog timer support compiled into the kernel if the window of activity is only 30 seconds
<TomTheDragon>
well, uptime is saying 55 or so
<TomTheDragon>
I'm not certain
<TomTheDragon>
isn't WDT turned off by default?
<inode>
i guess that depends on what your boot loader has initialized before jumping to the kernel
<TomTheDragon>
inode: In /sys/firmware/devicetree I was able to really hurry and find some kind of reference to watchdog. "state" was "disabled"
<TomTheDragon>
hard to save any of the work though because it's just too quick
<inode>
you could try decompile the device tree, enable it, recompile and pass it to the kernel at the next boot and try again
<TomTheDragon>
that'd be a weird option to set enable but, who knows
<inode>
why?
<TomTheDragon>
because if it's disabled, it can't kill the system
<TomTheDragon>
inode: also, you said you had luck by building rk3229 op-tee, uboot, and kernel. what actual system was that on?
<inode>
the build system?
<inode>
i listed the targets in README.md
<TomTheDragon>
inode: no, the target system
<inode>
mecer xtreme mini s6, and mxq 4k
<inode>
initially i started with the mecer xtreme mini s6, and i bought an mxq 4k to test the procedure with when someone had told me that they had trouble following along
<inode>
turns out the mxq 4k features nand flash, while the s6 has an emmc
<TomTheDragon>
yeah
<inode>
in any case, the sd option worked for the mxq 4k
<TomTheDragon>
I bought the mxq 4k under the impression all of them had S905W which seems to be more widely supported
<TomTheDragon>
and the seller claimed S905W, yay! at least I got a partial refund.
<inode>
that's lucky
<TomTheDragon>
but frankly, I'm unlikely to buy any non-raw boards in the future
<inode>
the one i got was advertised as having 2GB RAM and 16GB flash
<TomTheDragon>
if i can't see the PCB in question
<inode>
turned out i got 1GB/8GB instead and no recourse
<TomTheDragon>
actually, I read that watchdog timer will reset a system, not cause a solid hang
lkcl has quit [Read error: Connection reset by peer]
<TomTheDragon>
but who knows.. maybe android does it different. even though I'm not running android, it's an "android box"
<inode>
android does have something called wakelocks
<inode>
but i'd guess that the real issue lies in the how the bootloader has initialized the board
<TomTheDragon>
any documentation on that anywhere?
<inode>
and then in the kernel that is eventually loaded not playing by the rules the loader had hoped it would
<TomTheDragon>
is it in the dtb, some kind of param in uEnv.txt?
<TomTheDragon>
or in the compiled bootloader executable
<inode>
the answer lies somewhere in the disassembly of[4~ the uboot/trust pair shipped with your device
<inode>
and probably in the rk3229 TRM which i could never get a hold of
<TomTheDragon>
can the trusted stuff be stripped?
<inode>
what do you mean by stripped?
<TomTheDragon>
is it necessary for boot, or can it just be ignored?
<TomTheDragon>
like the op-tee stuff?
<inode>
it seems to be necessary for enabling PSCI and thus bringing up 3/4 of the cores
<TomTheDragon>
I see
<inode>
but i used op-tee instead
<inode>
not sure if rockchip used arm trusted firmware or not in their trust blob
<TomTheDragon>
also, does the uboot on the nand try to boot the kernel on sdcard? or is it the uboot from the sdcard?
<inode>
do you mean the uboot shipped on the nand along with android?
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
<inode>
if so, no - from what i could tell it only made an attempt to boot the kernel from a partition on nand probably labelled "kernel", and pulled in "boot" for the initrd and "resource" for the device tree blob and other garbage like a splash screen
<inode>
if i remember correctly, if you interrupted autoboot there were no commands compiled into uboot to imply that it had any recognition of (neither sd nor e) mmc devices
<TomTheDragon>
inode: yeah I don't see any reference to chain loading or anything in the bootloader's parameters partition
<TomTheDragon>
all I did was put in the sdcard, so I guess something else checks and favors the sdcard
<inode>
could be the initial loader
<inode>
installed at sector 0x40
<TomTheDragon>
hmm
<inode>
on the devices i have, i had to erase the initial loader on the onboard storage before the boot rom code would attempt to find a loader on the sd card
lkcl has joined #linux-rockchip
<TomTheDragon>
strange.
<TomTheDragon>
well, strange that I didn't have to do anything
<TomTheDragon>
Also weird that there's an empty "uboot" in my /boot
<inode>
is /boot a mountpoint or just a directory on /?
<TomTheDragon>
directory on /
<inode>
i wouldn't worry about its content then
<TomTheDragon>
there's also an empty 100M first partition. is uboot even visible in the filesystem anyway, though?
<inode>
no
<TomTheDragon>
ok, that makes sense
<TomTheDragon>
quick question, I have extracted several partitions to try to get the original dtb file
<inode>
it's in resource
<inode>
but you have to rip it out of it's packaging
<TomTheDragon>
seems to be in boot.img-second.gz
<TomTheDragon>
which is not a gz file and not a dtb
<TomTheDragon>
but seems to contain one
<TomTheDragon>
resource also seems to contain one
<inode>
ok
<TomTheDragon>
file begins with "RSCE"
<inode>
you can ignore the initial resource header for now
<inode>
find the first instance of "ENTR"
<inode>
it should be followed by a "rk-kernel.dtb" string
<TomTheDragon>
I see it. what's the best way to cut it out?
<inode>
the next 4 bytes should be a block offset into the file where the device tree blob begins
<inode>
the block size should be 512 byte iirc
<inode>
and i think the next 4 bytes were the device tree blob size
<inode>
both numbers were in little endian representation
<inode>
i can look at a backup and double check if that is incorrect
<inode>
but this device tree is not going to be of much help unless you are using the same or similar kernel version
<TomTheDragon>
oh, interesting
<TomTheDragon>
I might just try the same kernel version
stikonas has quit [Remote host closed the connection]
adjtm has joined #linux-rockchip
freekurt has quit [Read error: Connection reset by peer]
eballetbo[m] has quit [Read error: Connection reset by peer]
thefloweringash has quit [Write error: Connection reset by peer]
EmilKarlson has quit [Write error: Connection reset by peer]
stikonas has joined #linux-rockchip
eballetbo[m] has joined #linux-rockchip
bonechewer has joined #linux-rockchip
<stikonas>
oh, nice u-boot now automatically merges TPL and SPL into idbloader.img
warpme_ has joined #linux-rockchip
EmilKarlson has joined #linux-rockchip
thefloweringash has joined #linux-rockchip
yann|work has joined #linux-rockchip
<stikonas>
yay, I think I was able to boot rockpro64 almost without blobs, only 864 byte hdcp.bin was used (probably something to do with display port content protection, so maybe unnecessary too)
fireglow has quit [Remote host closed the connection]
fireglow has joined #linux-rockchip
<stikonas>
ok, that hdcp.bin is indeed unnecessary
warpme_ has quit [Quit: warpme_]
<fALSO>
stikonas, for rockpro64?
<fALSO>
stikonas, want the share the steps?
fireglow has quit [Quit: Gnothi seauton; Veritas vos liberabit]
<stikonas>
fALSO: yeah, I think I'll write a blog over this weekend, but basically everything just worked by running make and etc...
<fALSO>
which conf you used ?
<fALSO>
evb_rk3399 ?
<stikonas>
no, I think rockpro64_defconfig
<fALSO>
mainline u-boot?
<stikonas>
fALSO: yes
<stikonas>
very latest one
<fALSO>
ok stikonas thanks
<fALSO>
gonna do it!
<stikonas>
so very latest one creates idbloader.img
<stikonas>
which combines TPL and SPL
<fALSO>
and it boots ?
<stikonas>
well, you also need to compile ATF
<fALSO>
yes i know
<fALSO>
im using gentoo on my rockpro64
<fALSO>
but i havent been able to build the u-boot
<stikonas>
fALSO: I'm on gentoo too
<fALSO>
well i can build it, but the one i build doesnt boot
fireglow has joined #linux-rockchip
<fALSO>
gets always stuck on ram initialization
<fALSO>
before uboot
<stikonas>
it doesn't always boot, sometimes it does, sometimes it needs extra help
<stikonas>
maybe mmc rescan in u-boot
<fALSO>
so im using the u-boot bin from armbian
<stikonas>
or something like that
<fALSO>
im building ayufan kernel
<fALSO>
Linux rockpro64 5.3.0-rc4-arm64-g27e55528e #2 SMP PREEMPT Tue Sep 3 00:47:52 WEST 2019 aarch64 GNU/Linux
<stikonas>
fALSO: oh, RAM initialization started working for me recently (it was merged maybe a month ago)
<fALSO>
stikonas, AHH nice
<stikonas>
fALSO: I'm on 5.2.14-gentoo
<fALSO>
stikonas, gonna have to try it again
<stikonas>
with a couple of patches
<fALSO>
hum, youre using mainline kernel ?
<fALSO>
ahh
<fALSO>
because theres no support for rockpro64 still on the kernel