Bahhumbug has quit [Read error: Connection reset by peer]
Bahhumbug has joined #linux-rockchip
gnuiyl has quit [Remote host closed the connection]
gnuiyl has joined #linux-rockchip
Daanct12 has joined #linux-rockchip
raster has joined #linux-rockchip
warpme has joined #linux-rockchip
kevery has quit [Quit: kevery]
kevery has joined #linux-rockchip
kevery has quit [Quit: kevery]
kevery has joined #linux-rockchip
<Kwiboo>
naoki: regarding your "arm64: dts: rockchip: change pinctrl for pcie2x1l2 for Radxa ROCK 5A" patch: the split of pcie pin group already fixed the issue for u-boot so commit message no longer match why/what is done, so now look like your patch swap and rename pinctrl symbols without any explanation
<Kwiboo>
please send an updated patch stating that the rename of symbol is to match schematics and possible skip the reorder or at least mention the reorder
<naoki>
well,
<Kwiboo>
dropping the pins from pinctrl-0 seem like an unneccecery step? the pins are connected according to schematic
<naoki>
remove unused CLKREQ and WAKE pins, rename reset pin name to match witch schematic, and reorder
<Kwiboo>
on rk356x it is important to include all pins because they help indicate correct IO mux, not sure it is same for rk3588
<Kwiboo>
and hw and schematic have all 3 signals hooked, so they should be included in DT to be explicit about hw, not what feature are implemented in software
<naoki>
Kwiboo: about rk356x, kever yang said that unused pins by software should be default (GPIO)
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mripard has joined #linux-rockchip
<naoki>
I'm confused because I'm being told to do the opposite.
warpme has joined #linux-rockchip
<Kwiboo>
I can understand the confusion, and kevery is right, software does not make use of those pins, however DT is about describing the hw and is not intended to work as configuration for software features
<Kwiboo>
in my mind having the pins described in DT is more correct from hw viewpoint, as they exist and the pins/signals are wired according to schematics
<dsimic>
FWIW, I agree with Kwiboo's argument that the DT needs to describe the actual hardware
<dsimic>
if there are some resulting issues in the drivers, drivers need to be fixed
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<dsimic>
qschulz: thanks... ah, silly me, how did I miss those? :)
<dsimic>
why don't we replace those with panic()?
<qschulz>
Well... we could but I am not sure this is the wisest
<qschulz>
I'm wondering if we shouldn't simply panic() for ANY DRAM init issue
<dsimic>
perhaps, but these endless loops are the first, obvious candidates
<qschulz>
because right now, if the DRAM init fails (aside from those two while(1); infinite loops), we just print "failed" and go on with the boot process
<qschulz>
I mean, it wouldn't be too difficult to simply return -EINVAL for that function instead of void and have dram_init() read that return value and return it if non-zero as well
<qschulz>
and then from TPL/SPL instead of printing the error message we panic()
<dsimic>
hmm, how about replacing those two infinite loops with panic() first, to see how would the upstream react?
<dsimic>
and based on that, go further
<qschulz>
if we can do the thing properly instead of piling up work arounds on work arounds, it would be nice :)
<dsimic>
I can agree on that :)
matthias_bgg has joined #linux-rockchip
<dsimic>
would you like to do that yourself, or should I earmark that?
<qschulz>
will do myself as this is a pain point of mine, I want my RK3399 Puma to reboot themselves if they fail DRAM init
<qschulz>
otherwise it's bad for an embedded system to be stuck in the middle of nowhere :)
<dsimic>
totally agreed, it should be handled by panic(), which can be configured to hang if desired so
<dsimic>
please, Cc me when you submit the patches, so I don't miss them
warpme has joined #linux-rockchip
naoki has quit [Quit: naoki]
<qschulz>
Kwiboo: it seems like the sdram patches from Rockchip you sent on this chan earlier does fix my DRAM init issues on my picky RK3399 Puma? I'll let it run a bit more to be sure
<qschulz>
I had a hang in TF-A though (but that could be because I'm running the integration branch + some patches :) )
<qschulz>
and after 2200 reboots, one of the USB hubs was not detected, maybe you've experienced this in the past`, who knows
Stat_headcrabbed has joined #linux-rockchip
Daanct12 has quit [Quit: WeeChat 4.4.3]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<dsimic>
qschulz: sorry, what SDRAM patches are you referring to? I went again quickly through the channel history and wasn't able to spot them
<qschulz>
welp, DRAM init just failed on my RK3399 again :(
raster has quit [Quit: Gettin' stinky!]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dsimic has quit [Ping timeout: 260 seconds]
dsimic has joined #linux-rockchip
psydroid has quit [Read error: Connection reset by peer]
psydroid has joined #linux-rockchip
psydroid has quit [Read error: Connection reset by peer]
psydroid has joined #linux-rockchip
<qschulz>
dsimic: there you go
<qschulz>
mmind00: Kwiboo: mmmm, I looked into the OPP again on RK3399 in the kernel to increase the base core freq and boot faster
<qschulz>
in U-Boot I mean
<qschulz>
we have 600MHz currently hardcoded for both the LITTLE and the big clusters
<qschulz>
However, the big cluster can actually go up to 816MHz with the same voltage as 600MHz
<qschulz>
... but it's different between RK3399 and OP1
<qschulz>
600MHz @ 0.825-1.25V on RK3399, 600MHz @ 0.8V on OP1
<qschulz>
816MHz @ 0.825-1.25V on RK3399, 816MHz @ 0.825V on OP1
<qschulz>
is there a way to know (and guarantee) about the voltage for the big cluster on RK3399/RK3399-T/OP1 by any chance?
<mmind00>
qschulz: I'd assume the OP1 voltages should be the most occurate, because I'd think the ChromeOS people would've been quite pedantic with Rockchip to get acurate freq/voltage pairs
<qschulz>
mmind00: aren't there slightly different silicon (or binning at least?)?
<qschulz>
s/there/they/
<mmind00>
qschulz: yes
<mmind00>
qschulz: I meant, I'd consider the op1 OPPs as correct for the OP1 variant
<qschulz>
gotcha
vagrantc has joined #linux-rockchip
raster has joined #linux-rockchip
<rah>
I flashed a built u-boot to my roc-pc-plus and now it doesn't seem to want to enter maskrom mode..
<rah>
as I understand it, that shouldn't possible right?
<rah>
I get this on the serial line instead of maskrom mode:
<dsimic>
qschulz: mmind00: as an additional note, the OP1 should be the "creme de la creme" of the RK3399 binning; it can run the big cores faster, i.e. at 2 GHz, and the lower OPPs require a bit lower voltages than on the other RK3399 bins
<dsimic>
thus, the OP1 OPPs should actually include the voltage ranges, to allow higher voltages in case the associated regulators cannot deliver the exact voltages, and it's safe to run lower OPPs at higher voltages -- nothing wrong will happen, just more power will be used unnecessarily
<dsimic>
I'll move forward and send a patch that adds those voltage ranges to the OP1 OPPs, which may actually not be used on the supported boards (depending on the regulators), but are the right way to specify the OPPs
<dsimic>
qschulz: thanks for the patches, I'll review them a bit later
<dsimic>
qschulz: regarding increasing the boot frequency on the RK3399, I'm a bit worried about that, because even bumping it up to the next higher OPP that still uses the same voltage may actually increase the power draw, which may cause issues on some devices that may not negotiate the right profiles with their PSUs/chargers before the kernel takes over
ungeskriptet has quit [Killed (mercury.libera.chat (Nickname regained by services))]
ungeskriptet has joined #linux-rockchip
ungeskriptet is now known as Guest4709
Guest4709 has quit [Killed (lithium.libera.chat (Nickname regained by services))]
ungeskriptet has joined #linux-rockchip
raster has quit [Read error: Connection reset by peer]
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
<rah>
I seem to have bricked an unbrickable device :-/
<dsimic>
rah: where did you write this U-Boot build to?
diederik has quit [Ping timeout: 248 seconds]
stikonas has joined #linux-rockchip
naoki has joined #linux-rockchip
naoki has quit [Client Quit]
warpme has joined #linux-rockchip
warpme has quit [Client Quit]
diederik has joined #linux-rockchip
sL1pKn07 has quit [Remote host closed the connection]
sL1pKn07 has joined #linux-rockchip
sL1pKn07 has quit [Remote host closed the connection]
sL1pKn07 has joined #linux-rockchip
ungeskriptet is now known as Guest2102
Guest2102 has quit [Killed (platinum.libera.chat (Nickname regained by services))]