<apritzel>
MasterR3C0RD: $ git fetch origin ;-) v6.13-rc1 has been tagged
<MasterR3C0RD>
Yep, saw about ~30m ago. I'll send it off in about an hour; have it ready, just needs a rebase
<apritzel>
please don't forget to test as well: it's after the merge window, so there have been like 12,000 new patches applied meanwhile ...
<MasterR3C0RD>
Yep, I will; it's just device tree patches though, no code changes in this patch
<MasterR3C0RD>
Just happens that me and parthiban both have upcoming series that'll be depending on the syscon nodes, so this needs to be sent off separately as to not block either
junari__ has quit [Remote host closed the connection]
<MasterR3C0RD>
Looks like rc1 is rc1; lovely warning spam from mmzone.h
apritzel has quit [Ping timeout: 480 seconds]
junari has joined #linux-sunxi
junari has quit [Remote host closed the connection]
junari has joined #linux-sunxi
junari has quit [Remote host closed the connection]
junari has joined #linux-sunxi
junari has quit [Remote host closed the connection]
junari has joined #linux-sunxi
junari has quit [Remote host closed the connection]
junari has joined #linux-sunxi
ftg has quit [Read error: Connection reset by peer]
junari has quit [Remote host closed the connection]
junari has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
junari has joined #linux-sunxi
parthiban has joined #linux-sunxi
parthiban has quit []
parthiban has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
junari has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-sunxi
apritzel has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
apritzel has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
<Soupborsh>
I sent messages here, turns out my account logged out of oftc matrix bridge and messages were not sent.
<hlauer>
btw: Is there a way to stop the boring join/left messages in the oftc matrix bridge? Or in the elements matrix client?
<jakllsch>
on which side?
<hlauer>
So that at the end they are not visible in the elements view
<kepstin>
are you referring to user join/left messages? That's something that would have to be hidden in your matrix client. Element has a preference for that.
<kepstin>
Tho note that it'll affect every room you're in, not just irc rooms.
warpme has joined #linux-sunxi
<apritzel>
Soupborsh: this old meminfo wasn't updated for a decade or so, and it will not give you anything useful
<apritzel>
if you have an update image or an image from the flash, you can try to run "sunxi-fw info -v" on it, and see if it gives you anything useful
<apritzel>
Soupborsh: try to use MasterR3C0RD's recent PR, and see if the A133 column makes more sense (the A64 and H616 don't look quite right in your dump): https://github.com/apritzel/sunxi-fw/pull/6
<MasterR3C0RD>
apritzel: Shoot, I keep forgetting to finish up my fixes and push them up. Constantly getting nerdsniped by some thing or another
<MasterR3C0RD>
I was nearly though all of the suggestions before other things came up, so it shouldn't be much longer until I update that PR
<Soupborsh>
Also I was trying to execute extracted u-boot, boot0, fel sd card image, hello serial image in fel using write and exe commands but it does not work. I get -7 usb something error.
bauen1 has joined #linux-sunxi
<Soupborsh>
I have this question: Is there a way to initialize boot1 from FEL if it is uninitialized? I cannot enter FEL by using other way, only one works.
BroderTuck has joined #linux-sunxi
<BroderTuck>
b288 is a 32 bit soc, right? Unlike the socs used for column headings by this tool
warpme has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
anarsoul has quit []
anarsoul has joined #linux-sunxi
warpme has joined #linux-sunxi
warpme has quit []
ftg has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
<BroderTuck>
Soupborsh: Seems like the first column (marked A64) is the one to use. The commit that adds this dram value dumping to the sunxi-fw tool mentions "one older, used on the H3 and A64 generation, and one newer, as seen on boot0's for many H616 boards.", and the b288 is much closer to the H3 than any of the other Socs discussed.
<apritzel>
it seems like BroderTuck is right: unlike the newer 32-bit SoCs, the B288 is more in the H3 camp
<apritzel>
so for the dram_sunxi_dw.c we only need a few parameters, namely the ZQ value, frequency and type, plus a boolean ODT enabled
<apritzel>
but there are differences in this driver between the supported SoCs, so it could well be that the B288 is a special snowflake as well
colinsane has quit [Ping timeout: 480 seconds]
colinsane has joined #linux-sunxi
<apritzel>
Soupborsh: you could try it, try all of the supported SoC types in this DRAM driver, with CONFIG_DRAM_CLK=672 and CONFIG_DRAM_ZQ=3881977. DRAM type should be the default DDR3
<apritzel>
BroderTuck: fyi: there are a bunch of newer A7 based SoC (starting with the V5), there are much closer to the newer 64-bit SoCs like H6, H616 or D1, and don't have much in common with the older H3 generation
<loki666>
apritzel: looks like change opp voltage is not the whole story on H700... I still have some crashes
<loki666>
it's better than before...
<loki666>
could it be that the governor is trying to changes the freq faster than the pmic can follows
<loki666>
leading to freq undervolted
<loki666>
I don't know much the algo of the govs, but here is my results, ofc, powersave is satble, perf is stable (even a 1.5) like rock solid
<loki666>
conservative is more stable than ondemand, which is more stable than schedult
<loki666>
userspace is stable even with a script trying to change the freq at 100Hz
<loki666>
I mean 100 times par sec
<loki666>
pmic is addressed over I2C, don't know if that matters
<loki666>
I'm sure I'm using the same freq and voltages (checked against a running bsp)
<loki666>
overall stability also seems to be device dependent, one of my H700 seems to crash less easily
BroderTuck has quit [Quit: Bedtime]
warpme has joined #linux-sunxi
<apritzel>
mmmh, can you somehow figure out if the crashes occur when stepping up or down?
<apritzel>
that could answer that question: for stepping up, we adjust the voltage first, then the freq. So if the PMIC takes too long, it would show problems
<apritzel>
on the way down it's freq first, then voltage, so delays in the PMIC wouldn't matter
<loki666>
I'll tweak my script to force ramping freq up
<loki666>
do bigger freq jump could make a change ?
<loki666>
a difference I mean
<apritzel>
the jump should be big enough to really require that voltage. As chances are that some OPPs requiring say 950mV would also work on 900mV still. So the delta should be big enough
<loki666>
ok, I see I'll test that
<apritzel>
loki666: but this whole thing is a good idea of you to follow, I guess there are standard DT properties to delay the frequency stepup after adjusting the voltage?
<loki666>
clock-latency-ns = <244144>; is set on every opp
warpme has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
<loki666>
I guess I can try to double that value
<apritzel>
well, I found this as well, but I don't really understand what that means. And it seems clock related? Is that an estimation of how long the clock change takes?
<apritzel>
so the AXP datasheet says the default is 15.625 us/step, which is 10mV in our case. So going from 900mV to 1100mV should take 312.5 us
<loki666>
bsp dcdc1 (cpu reg) has this property regulator-ramp-delay = <0xfa>;
<loki666>
not in mainline
<apritzel>
the property is supported though, and we use it for the H6 boards, for instance
<loki666>
so I should just add it ?
<apritzel>
give it a try. In the H6 .dts files it's 2500, not 250, though, not sure if the unit is different
parthiban has quit [Remote host closed the connection]
<loki666>
.yaml says unit is uV/us
parthiban has joined #linux-sunxi
<apritzel>
yes, just found this as well ;-)
<apritzel>
let's see who is faster in calculating this value ...
<apritzel>
yeah, looks like a bug: DCDC1/2/3 all support this ramping, and it's enabled by default, so we should declare it in the DT
<apritzel>
at least for DCDC1, the others are fixed anyway
<loki666>
640 uv/us ?
<apritzel>
dammit, you beat me by about a second ;-)
<apritzel>
same value I came up with
<loki666>
yay
<loki666>
ok I'll try that
<loki666>
but not today, thanks for the help I'll let you know, and retry the with the values currently in mainline, hopefully, my patch will be a one liner
warpme has quit [Read error: Connection timed out]
<apritzel>
sounds good, and good finding!
<apritzel>
Soupborsh: I guess you have some boot0 binary? What I regularly (try to) do is to hack boot0 and overwrite some code after the DRAM init with a branch to 0x20, so it goes to FEL
<apritzel>
so then you wouldn't need to waste time on the BSP U-Boot
warpme has joined #linux-sunxi
ftg has quit [Read error: Connection reset by peer]