<anarsoul>
I'm not sure why you think that my patch "rockchip: rk3399: rockpro64: enable force power on reset workaround" toggles VSEL
<anarsoul>
it doesn't
<anarsoul>
it sets OTP_OUT to 1
<anarsoul>
and thus forces over-temperature protection reset
<anarsoul>
so technically it's a sledgehammer but I don't know how to debug the issue further
<kevery>
Sorry, I didn't notice this, because you and origin commit from theobromasystem never mention the pin is for OPT_OUT, so I though it's for VSEL without a check.
<kevery>
Will check this OTP_OUT.
<anarsoul>
see "over-temperature protection" circuitry, basically if you set this pin high it's an equivalent of pressing reset button
<kevery>
OK, so I got it, the difference is the hardware reset vs software reset.
<anarsoul>
yes
<anarsoul>
software reset doesn't reset something so linux can't boot afterwards
<anarsoul>
regulators are already checked and unlikely to be the issue
<kevery>
These two reset is the same for RK3399, but different for the hardware other than RK3399, the main difference would be the PMIC RK808. do you able to measure the voltage output of RK808, eg. voltage for CPU_L, which is the most important at kernel start up.
<anarsoul>
kevery: I checked RK808 registers and they're almost identical
<anarsoul>
I'm not sure if there're any test points to measure CPU_L voltage, I'll ask TL for instructions on how to do that
<kevery>
But you said you have disable the CPUFREQ and have the same result, that's strange.
<anarsoul>
kevery: do you have any board with rk3399 and rk808 to try it yourself? I believe you have better tools and skills to debug this issue than me
<kevery>
On rockchip branch, we will restore a safe voltage for pmic regulator which need dvfs, use a notify callback for reboot event.
<anarsoul>
kevery: well, u-boot works fine so I assume voltages are OK
<anarsoul>
(also I checked rk808 and syr83x registers)
<kevery>
no, U-Boot works at 600MHz, and kernel at 800MHz
<kevery>
either disable the cpufreq, or remove the 408M and 600M at kernel cluster0_opp should able to make it work if this is the root cause.
<anarsoul>
I disabled cpufreq, so kernel shouldn't control cpu frequency at all
<kevery>
Let me check on excavator board
<anarsoul>
please try with mainline u-boot and mainline ATF
vstehle has quit [Ping timeout: 240 seconds]
<anarsoul>
I can try with rock pi 4 this weekend
<anarsoul>
anyway it needs a fix (the same as for rockpro64) to get USB working in u-boot
stikonas has quit [Remote host closed the connection]
ganbold has joined #linux-rockchip
<kevery>
One suggestion for you (to debug question related to soc) could be replace one or two component for vendor to check if the function works, and then try to find the difference. Many patches are port from vendor branch to upstream, rockchip kernel and U-Boot are open source.
<kevery>
The excavator with mainline u-boot+atf+kernel: hang at reboot; then I replace the atf with rkbin bl31, the reboot works correctly, no hang happen during kernel start up.
<flacks>
kevery: are you only substituting ATF with rkbin bl31? i.e. only build u-boot with rkbin bl31, and *not* using the miniloader?
mrjay has quit [Remote host closed the connection]
kevery has quit [Quit: kevery]
BenG83 has joined #linux-rockchip
<BenG83>
hi, does anyone know when the EXT_EN output on the RK808 rises during power-on? I can't find it in the datasheet or timing diagrams
inode has quit [Quit: ]
vagrantc has quit [Quit: leaving]
kaspter has quit [Quit: kaspter]
pcbBob has quit [Remote host closed the connection]
field^Zzz3 has joined #linux-rockchip
JohnDoe_71Rus has joined #linux-rockchip
ldevulder_ has joined #linux-rockchip
ldevulder has quit [Ping timeout: 268 seconds]
<phh>
does someone know how to use/flash debian's u-boot-rockchip package?
<phh>
I read the readme, which says to dd firefly-rk3288/u-boot.rksd to block device with seek=64; and so i blindly dd firefly-rk3399/u-boot-spl.rksd seek=64, and i guess that was a mistake because now on the serial I just get "U-Boot SPL board init"
<phh>
i guess my mistake is that for rk3288 it's first bootloader while for rk3399 it's secondary bootloader so probably not the same address...
<phh>
should i keep miniloader for primary boot loader?
<flacks>
phh: what device?
<phh>
firefly rk3399
<flacks>
you sure you wrote to the right device?
<flacks>
did you write to the card from the OS or from a different machine i.e. with SD card plugged in via USB/slot
ldevulder__ has joined #linux-rockchip
<flacks>
hm either way, yeah, u-boot-spl.rksd is tiny
<flacks>
96KiB
<phh>
i have no sdcard plugged, and I flashed to mmcblk1
<phh>
(only mmc device appearing)
<phh>
and i definitely managed to brick the board, so it was the correct target :P
<flacks>
right hehe
<flacks>
so you need to find out what hooks update the bootloader on debian
ldevulder_ has quit [Ping timeout: 265 seconds]
<flacks>
because there are no instructions in the u-boot-rockchip package for firefly rk3399
<flacks>
so you need to find the hooks to know what files it uses
<flacks>
and how it flashes them
<phh>
considering README.Debian, it looks like user is expected to flash it manually
<flacks>
there are two potential targets for flashing at 0x4000, `u-boot.bin` and `u-boot.img`, but idk which one to you should use
<flacks>
assuming one of them has ATF bundled
<flacks>
hm, there is README.rockchip which has more info
<phh>
well that's u-boot's README.rockchip
<flacks>
hm
<sigmaris>
phh: I think as well as writing the SPL at 64 sectors, you need to write u-boot at 16384 sectors
<flacks>
why not try building u-boot yourself?
<flacks>
then at least you'd know exactly what to flash and where to flash them
<phh>
flacks: yeah i guess...
<flacks>
right, the trouble is identifying which of the u-boot images bundled in that package you need to flash at sector 16384
<flacks>
I guess you can try themn both! :)
<flacks>
I'd try `u-boot.img` first
<phh>
(well atm i'm still un-bricking it)
<flacks>
your first partition starts at 0x8000 righta?
<phh>
(if you have another "standard" Linux distribution that you can recommend that has better support for such things, feel free to recommend)
<flacks>
there's no documentation on what each of those are
<flacks>
well, a few are self-explanatory, but it's unclear to me which is the u-boot img to flash to 0x4000
<flacks>
phh: best is to build it yourself. every distro does things differently
<robmur01>
hmm, just looks like the byproducts of a u-boot build, which for a miniloader config are all irrelevant except u-boot.img
<phh>
fwiw, i don't specifically want miniloader, and i see that u-boot has RAM timing for this board, so I can live without it, correct?
<flacks>
robmur01: actually you're right, I guess I'm just tired and grumpy :)
<flacks>
phh: yes; give it a test. IIUC there is a reboot issue with rk3399 in general, but it does boot, and resetting a rockpro64 with this issue results in functional boot once again
<robmur01>
with mainline u-boot you can use SPL/TPL instead, but then you need the u-boot.itb version of the main stage image
<phh>
k k, i'm building master u-boot
<rtp_>
phh: as regards debian's uboot package, you may want to ask vagrantc (who is often here I think). There are chances he'll be able to answer some questions
ifbizo has quit [Ping timeout: 260 seconds]
ifbizo has joined #linux-rockchip
<phh>
k, instructions to build & flash u-boot in doc/README.rockchip works fine, I just had to fight to find a working miniloader to boot on maskrom (I ended up extracting the MiniLoaderAll.bin from a working ubuntu 16.04 image from firefly...)
<flacks>
why not use upstream u-boot SPL/TPL?
<phh>
? that's what I just did
<phh>
miniloader is used only for flashing
<phh>
and it's the recommeded method from uboot master readme
<flacks>
flashing to... SPI?
<phh>
no, to eMMC
<flacks>
oh, I see
ifbizo has quit [Remote host closed the connection]
ifbizo has joined #linux-rockchip
ifbizo has quit [Remote host closed the connection]
ifbizo has joined #linux-rockchip
pcbBob has joined #linux-rockchip
BenG83 has quit [Quit: Leaving]
<paulk-leonov>
mhh I'm experiencing aux CPUs bringup failure on px30
<paulk-leonov>
with 5.4
<paulk-leonov>
does that ring a bell to anyone?
matthias_bgg has quit [Ping timeout: 268 seconds]
<phh>
(and so I managed to launch debian sid netboot installer, stable has broken ethernet, but sid needs to edit initramfs to remove fan53555 to boot)
chewitt has quit [Quit: Zzz..]
ifbizo has quit [Remote host closed the connection]
ifbizo has joined #linux-rockchip
vagrantc has joined #linux-rockchip
return0e has quit [Read error: Connection reset by peer]
return0e has joined #linux-rockchip
ifbizo has quit [Remote host closed the connection]
ifbizo has joined #linux-rockchip
ifbizo has quit [Remote host closed the connection]
ifbizo has joined #linux-rockchip
vicencb has joined #linux-rockchip
ldevulder__ is now known as ldevulder
ifbizo has quit [Remote host closed the connection]
ifbizo has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
pcbBob has quit [Remote host closed the connection]