<dsimic>
if there's no "SPI disable" jumper or switch on your board, you can short the SPI clock (the pin on the chip itself) to ground using fine-tip tweezers or a safety pin, to disable the SPI chip and boot from a microSD card
<qschulz>
dsimic: was there really negociation with the chargers on RK3399 devices already?
<rah>
dsimic: you mean the SPI clock pin on the flash chip?
<qschulz>
dsimic: yeah ok, the RockPI4+ seems to have USB-PD already
<qschulz>
so, the other thing I'm wondering is how the power rail to the CPUB/CPUL clusters is configured by U-Boot
<qschulz>
if at all
<qschulz>
because otherwise we probably have an issue
<qschulz>
e.g. let's take the example of the OP1. The voltage for the min OPP is 800mV
<qschulz>
for 600MHz it's 825mV
raster has joined #linux-rockchip
<qschulz>
if for some reason we trigger the internal SoC watchdog while running at the lowest OPP
<qschulz>
then the PMIC won't be reset
<qschulz>
same for its power rail for the CPUB/CPUL
<qschulz>
and U-Boot sets the CPUL/CPUB frequency to 600MHz for all RK3399 (normal/T/OP1) to 600MHz whwnever the clock driver is probed (xPL or not)
System_Error has quit [Ping timeout: 260 seconds]
<dsimic>
qschulz: there's also the PinePhone Pro
<dsimic>
rah: exactly, the SPI clock pin on the SPI NOR chip itself
<qschulz>
dsimic: uhhhh... not according to the DT?
<dsimic>
yeah, the PinePhone Pro DT is still rather incomplete :/
<qschulz>
dsimic: why is it not using the OP1 OPPs then?
<qschulz>
dsimic: ah you meant the PinePhone pro does USB-PD?
<qschulz>
I was looking at your OP1 OPP patch, so mixed things up most likely :)
<dsimic>
yes, but it uses only the 3 A / 5 V profile
<qschulz>
ack
System_Error has joined #linux-rockchip
<dsimic>
regarding the voltage regulators for the clusters, we should be configuring them in U-Boot
<qschulz>
the sentence can be interpreted two ways, are we currently doing it or should we add support for it
<dsimic>
those are usually realized as programmable discrete regulators, so we should be, well, programming :) them accordingly in U-Boot
<dsimic>
I haven't checked it myself, but if we don't do that already, we need/should to
<dsimic>
we might even save some power that way in U-Boot, because I'm not sure what's the default voltage for those regulators
<dsimic>
so we might end up running at too high voltages for the OPP
<qschulz>
depends on the silicon
<dsimic>
perhaps, but that's just another reason to configure those regulators in U-Boot
<qschulz>
they can actually be customized via fuses during manufacturing by the vendor most of the time
<qschulz>
clocks are a bit... special in U-Boot, at the very least for Rockchip SoCs
<dsimic>
according to the SYR837 datasheet, which is used on the RockPro64, its default voltage is 1.0 V
<qschulz>
yeah but that isn't something we can rely on unfortunately
<qschulz>
because we may inherit a state from a previous boot (warm boot)
<dsimic>
but what about cold boots? e.g. the PinePhone Pro experiences power-related boot issues when there's no battery installed, and there's no PD negotiation in place, which may be mitigated by lowering the power consumption in U-Boot
<dsimic>
not only mitigated for the PPP example, but also made more reliable in general, because lowering the power consumption at those early stages can only be good
<dsimic>
ah, I see what you meant
<dsimic>
things get wven worse on warm boots
<dsimic>
s/wven/even/
<qschulz>
incorrect voltage for an OPP can basically trigger brownout (pulling too much power while the power isn't configured properly just yet)
<dsimic>
exactly
<qschulz>
or stability issues if you're running an OPP at lower voltage than expected
<dsimic>
yes, which is even worse from the "being technically correct" point
<qschulz>
well... brownouts, we would hopefully "recover" by having the board reset itself
<qschulz>
hopefully not a bootloop
<qschulz>
but stability issues are really not nice to work with :)
<qschulz>
bitflips and all
<dsimic>
indeed
<dsimic>
those are just the additional reasons to configure those regulators in U-Boot
<qschulz>
yes, but I don't think this is really straightforward as it is today
<qschulz>
especially if you count in the stability issues we have with RK3588 in upstream Linux for example
<dsimic>
well, we can work on all that
<qschulz>
yeah, that's a big can of worms to open I believe
<qschulz>
but could drastically decrease boot time
<qschulz>
(in addition to the potential stability improvements)
<dsimic>
the latter are even more important, IMHO, but faster boots would be great
<qschulz>
I think it's easier to get people to work on getting things faster than more stable :D
<rah>
dsimic: how can I erase the SPI flash?
warpme has quit [Read error: Connection reset by peer]
warpme_ has joined #linux-rockchip
<rah>
I removed the short after booting and tried running "rkdeveloptool ef" but it still errors out on boot
<qschulz>
rah: how did you build U-Boot for your roc-pc-plus?
<rah>
(and doesn't enter maskrom mode)
<qschulz>
rah: SPI erasing from rkdeveloptool doesn't work for RK3399
<qschulz>
I reported this to Rockchip but they said they will not fix it
<rah>
qschulz: made the roc-pc config and then replaced all the instances of "rk3399-roc-pc" with "rk3399-roc-pc-plus"
<qschulz>
rah: yeah that's not going to work
<rah>
ooof
<qschulz>
rah: do you have another storage medium than SPI for your board?
<qschulz>
what I do is booting from SD card/eMMC and then run sf probe 0; sf erase 0 0x400000 or whatever is the size of your SPI NOR
warpme_ has quit [Read error: Connection reset by peer]
<rah>
yes, there's eMMC which I'm tried to install Debian to but then it wouldn't boot after; I presume the Debian partition table overwrote u-boot
<qschulz>
yeah that's possible
warpme has joined #linux-rockchip
<rah>
hence trying to put u-boot on the SPI
<qschulz>
yes, but that is fucked too now :D
<rah>
indeed
<qschulz>
so, if you short the clock for SPI AND eMMC, you should be able to enter the download mode
<qschulz>
then you can flash an eMMC image there
<qschulz>
and erase the SPI NOR from there
warpme has quit [Read error: Connection reset by peer]
warpme has joined #linux-rockchip
<dsimic>
rah: I'd just boot Linux from a microSD card and erase the SPI chip from there
warpme has quit [Client Quit]
<qschulz>
if you have an SD card slot, for sure yes
<dsimic>
oh, that board has none?
<qschulz>
will be easier to do trial and errors on it
<qschulz>
dsimic: I don't know, they said SPI and eMMC, so I don't know :)
<rah>
=> sf probe 0
<rah>
Failed to initialize SPI flash at 1:0 (error 0)
<rah>
jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 20, 70, 18
<dsimic>
qschulz: I'm willing to open that can or worms as part of my work on the Rockchip SoC binning... I'll have to perform a whole mountain of stability testing for the SoC binning, so throwing in U-Boot stability testing wouldn't add much to that mountain
<qschulz>
rah: don't know sorry, maybe we need to add some ID somewhere?
<qschulz>
rah: so, to progress further with U-Boot, you'll essentially need to do the same as for the Mezzanine version of the Roc-PC
<dsimic>
as a suggestion, testing U-Boot builds is, in general, better to be performed using removable media first, which usually boils down to using a microSD card
<dsimic>
unless that board really has no microSD slot, of course
warpme has joined #linux-rockchip
warpme has quit [Remote host closed the connection]
warpme has joined #linux-rockchip
<rah>
I don't think I'm going to take on a u-boot dts right now anyway
warpme has quit [Read error: Connection reset by peer]
warpme has joined #linux-rockchip
<dsimic>
the ML is very slowly delivering messages today :/
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
naoki has quit [Quit: naoki]
warpme has quit [Read error: Connection reset by peer]
warpme_ has joined #linux-rockchip
warpme_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
<warpme>
quys: was anybody played with av1 hw.decoding on r3588?
dsimic has quit [Ping timeout: 276 seconds]
dsimic has joined #linux-rockchip
warpme has quit [Read error: Connection reset by peer]
warpme has joined #linux-rockchip
Bitweasil has quit [Ping timeout: 260 seconds]
Stat_headcrabbed has joined #linux-rockchip
Bitweasil has joined #linux-rockchip
<linkmauve>
warpme, I am, attempting to add AVIF decoding to my Onix library.
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
warpme has quit [Read error: Connection reset by peer]
warpme has joined #linux-rockchip
mripard has quit [Quit: WeeChat 4.4.2]
mripard has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guest12 has joined #linux-rockchip
warpme has joined #linux-rockchip
warpme has quit [Client Quit]
Guest12 has quit [Ping timeout: 256 seconds]
<linkmauve>
Hi, I’ve just built drm-next for my rk3588, but I only have the panthor card0 in /dev/dri, no card for the KMS stuff.
<linkmauve>
I think I have all the PHY and controller drivers enabled to get at least HDMI.
<linkmauve>
Oh wait, dmesg says [ 1.255294] rockchip-drm display-subsystem: [drm:rockchip_drm_platform_probe] *ERROR* No available vop found for display-subsystem.
<linkmauve>
I do have CONFIG_ROCKCHIP_VOP2=y so that should be working I think.
vagrantc has joined #linux-rockchip
<linkmauve>
There is one port that gets tested in rockchip_drm_platform_of_probe(), but it has no parent and thus doesn’t get used.
<linkmauve>
In rk3588-base.dtsi, I see ports = <&vop_out>; in display-subsystem, which itself references four ports.
<linkmauve>
Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml only mentions rockchip-vop.yaml, shouldn’t it also mention rockchip-vop2.yaml?
<linkmauve>
I find it weird that it only tests one port, whereas vop_out has four of them.
<linkmauve>
Yay, with a &vop { status = "okay"; }; in my board’s .dts, it works!
<linkmauve>
I just completely forgot about the status = "disabled"; in the dtsi…
<linkmauve>
Thanks for being there rubber ducks. :)
<helene>
quack
<linkmauve>
Although, there are planes, eight of them, but no connector, encoder or CRTC.
<linkmauve>
&hdptxphy_hdmi0 { status = "okay"; }; wasn’t enough to enable a connector for it. :(
<linkmauve>
I do have CONFIG_PHY_ROCKCHIP_SAMSUNG_HDPTX=y, hmm…
krei-se has quit [Read error: Connection reset by peer]
krei-se has joined #linux-rockchip
krei-se has quit [Read error: Connection reset by peer]
krei-se has joined #linux-rockchip
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
Guest12 has joined #linux-rockchip
stikonas has joined #linux-rockchip
<rah>
I lied, I tried a quick and dirty u-boot dts, which kind of worked
<rah>
I used the original Armbian u-boot and it's working fine
<rah>
I have Debian installed, with empty SPI flash
raster has quit [Quit: Gettin' stinky!]
System_Error has quit [Remote host closed the connection]
Ermine has quit [Ping timeout: 245 seconds]
Whistler has quit [Ping timeout: 245 seconds]
Ermine has joined #linux-rockchip
<linkmauve>
Ah, with Cristian Ciocaltea’s series it goes further, now I have a connector, an encoder and a CRTC, but still no signal.
Whistler has joined #linux-rockchip
<linkmauve>
The connector has no physical size, no EDID, but it says it’s connected.
System_Error has joined #linux-rockchip
<linkmauve>
After starting weston the EDID and the modes have been read! \o/
<linkmauve>
It still doesn’t display anything to the screen, but progress. :)
<linkmauve>
It’s weird, previously every plane was an Overlay, now one of them became Primary, it’s one which supports only AFBC modifiers, no LINEAR.
<linkmauve>
Yay, it works!!! \o/
<linkmauve>
Thanks again helene, and every other rubber duck present here. :)
<helene>
gj on figuring it out! :)
<linkmauve>
The last issue was that I had to force the 1920×1080 mode, as the default and preferred mode of 1360×768 didn’t light up the display, nor any other mode that I could test.
<linkmauve>
I’ll report that to Cristian.
Guest12 has quit [Ping timeout: 256 seconds]
<CounterPillow>
-o< quack
raster has joined #linux-rockchip
raster has quit [Read error: Connection reset by peer]