<naoki>
(actually I couldn't understand what Lee Jones want...)
<dsimic>
hmm, but why did you submit those patches for ZERO 2 Pro?
<dsimic>
you could've just renamed the model name from "Radxa ZERO 2" to "Radxa ZERO 2 / ZERO 2 Pro" in the original board dts file, for example
<dsimic>
if the boards are 100% compatible, there's no point in introducing a new board dts file
<dsimic>
I'd suggest that you submit new patches that basically revert those changes
<dsimic>
actually, I'd _highly_ suggest that you submit those patches
<dsimic>
regarding the commit message, I can help, please ping me in about a couple of hours
<naoki>
I wanted to change file name like zero-2-pro, but now I'm feeling just change model name is better...
<dsimic>
basically, DTs describe hardware
<dsimic>
so if two boards are identical, having two DTs is simply wrong
<dsimic>
especially because the board was just renamed for marketing purposes
System_Error has quit [Ping timeout: 260 seconds]
<dsimic>
maybe you can still ask the maintainers to drop those patches
<dsimic>
anyway, it's up to you and I don't care much about Amlogic boards, but having the additional board dts file is simply wrong
<naoki>
I sent email to the maintainer
<naoki>
dsimic: please help me about commit message...
<dsimic>
sure, in about an hour or so
<dsimic>
I'm a bit busy at the moment :)
<naoki>
I see, thanks
kevery has quit [Ping timeout: 248 seconds]
<dsimic>
anytime :)
kevery has joined #linux-rockchip
shailangsa has joined #linux-rockchip
sjoerd5 has joined #linux-rockchip
sjoerd has quit [Ping timeout: 252 seconds]
sjoerd5 is now known as sjoerd
Daanct12 has quit [Ping timeout: 252 seconds]
Daanct12 has joined #linux-rockchip
System_Error has joined #linux-rockchip
<dsimic>
naoki: regarding the commit message, you were asked not to "recycle" a comment from another file, but to describe the reasoning in prose, using your own words
<dsimic>
basically, you need to describe what you do in your patch, and why you do that
<dsimic>
but using your own words, providing as much detail as possible, including the specific platform on which the issue was observed and fixed, i.e. E25
warpme has joined #linux-rockchip
<naoki>
oh... I don't know "why", I just found difference between leds-pwm an leds-pwm-multicolor, and that comment sounds reasonable...
<dsimic>
well, you _need_ to know why
<naoki>
sure
<dsimic>
in other words, all patches should be based on knowing exactly why, how and where
<naoki>
otherwise I cannot say my fix is correct ;)
<dsimic>
and allo those details should be provided in the commit summary
<dsimic>
s/allo/all/
<dsimic>
exactly, that's how you prove that your fix is reasonable and correct
<dsimic>
and how you provide as much detail as possible for possible regression debugging later
<dsimic>
regarding this specific patch, you may even want to connect a scope to the PWM outputs that drive the LED on E25, to see exactly what's happening
<dsimic>
(if needed to go that far, of course)
<naoki>
problem is that I don't know much about pwm, electrical circuits, etc
<dsimic>
in that case, start learning today :)
<naoki>
anyway, thank you very much for you help
<dsimic>
I'm happy to help
<dsimic>
would you like me to recommend you a book?
<naoki>
written in Japanese? ;)
<naoki>
2nd problem is it's difficult to explain detail in English ;)
<dsimic>
then start learning English today :)
<naoki>
haha
<naoki>
sure
<dsimic>
I'm not a native speaker either, and it took me many years to reach the current level
<dsimic>
e.g. I spent 2.5 years on English Wikipedia, writing articles and learning written English
<naoki>
(it's a kind of routine like savedefconfig)
<dsimic>
mps: I'd say that English is actually deceptively simple
<dsimic>
naoki: such commit descriptions leave a lot to be desired :)
<dsimic>
mps: I tried learning Latin, and it's waaay harder than English, IMHO
<mps>
dsimic: yes, so simple that you cannot express deep thinking in it ;-)
<mps>
also, nearly half of words and terms in english are from latin
<mps>
knowing latin helps a lot to understand other european langs
kevery has quit [Ping timeout: 252 seconds]
ldevulder has joined #linux-rockchip
<dsimic>
no, no, you can express whatever you want in English :)
<dsimic>
I wanted to say that many people think they know English, while they actually don't
<dsimic>
BTDT... you need to know it very well, before realising why you didn't know it very well before :)
<dsimic>
regarding Latin, perhaps knowing it helps
<diederik>
FTR: your English doesn't have to be 'perfect' to write a good commit message
<dsimic>
true
<diederik>
Just explain to the best of your (English) abilities what you did and most importantly *why* you did it. The more justification for why, the better
<mps>
yes, I often excuse for "my bad english" but readers usually says it quite fine (maybe somewht 'speial' :) )
<mps>
s/speial/special/
<warpme>
guys: can anybody hint me how to say to kernel to NOT use given memory region? I'm trying with Kernel command line: root=/dev/mmcblk0p2 rw rootwait earlycon=uart8250,mmio32,0xfeb50000 console=ttyS2,1500000n8 debug memmap=0x80000000$0xBFFFFFFF but i'm getting: Unknown kernel command line parameters "memmap=0x80000000$0xBFFFFFFF", will be passed to user space. ....
<dsimic>
warpme: are you going to upstream your eMMC LED patch?
<mps>
warpme: is memmap supported on arm arch
<warpme>
ah - i'm not sure it is ready to upstream: it not correctly handles capability to drive separate read vs. write leds :-(
<warpme>
mps : i'm not sure and....it look like not :-(
<mps>
also I'm not sure but looks like it is not
<warpme>
is there any other way to disable mem region from use @ arm?
<warpme>
option is to reflow or reball but this is costly and not 100% guarantee (e.g. when issue is via on pcb; but iirc mem bus should not use via due impedance imparity between bus lines)
<dsimic>
reflowing should be inexpensive in any cellphone repair shop
<dsimic>
it's quite suspicious how regular the failed reads are
<warpme>
diederik : why new u-boot? Current one works perfect for other 6 rk3588 bords i have in lab. also iirc my dram training blob is most current one....
kevery has joined #linux-rockchip
<dsimic>
ch:3 dq0 fail,write:0x1,read:0x2
<dsimic>
ch:3 dq1 fail,write:0x2,read:0x4
<dsimic>
ch:3 dq2 fail,write:0x4,read:0x8
<dsimic>
ch:3 dq3 fail,write:0x8,read:0x10
<dsimic>
ch:3 dq4 fail,write:0x10,read:0x20
<dsimic>
ch:3 dq5 fail,write:0x20,read:0x40
<dsimic>
ch:3 dq6 fail,write:0x40,read:0x80
<dsimic>
ch:3 dq7 fail,write:0x80,read:0x0
<dsimic>
see the pattern? that's really strange
<warpme>
dsimic isn't this exactly points to 1 failing line in dram bus?
<dsimic>
the trouble is that read values are twice as large
<dsimic>
if they were smaller, then a falied line would make sense
<dsimic>
failed *
raster has joined #linux-rockchip
<dsimic>
it looks like the reads behave if there was a shift register somewhere
stikonas has quit [Quit: Konversation terminated!]
System_Error has quit [Ping timeout: 260 seconds]
<warpme>
dsimic : indeed this look more like dram chip failure than connectivity on pcb (e.g. cold solder). Interesting is that issue is definitely temperature triggered: starts happen after 5..10min of operation. power off for 5min+ brings board back. Using spray freezer on dram chip results with immediate back to operational. thats why my initial hypothesis was cold solder....
raster has quit [Quit: Gettin' stinky!]
<warpme>
so - for excluding dram bank usage from kernel - currently i see only DT option (and not by overlay as mainline don't have ov support). Any other ideas?
<dsimic>
I don't see another option
<warpme>
dsimic : thx!
<dsimic>
it's interesting that such regular DRAM chip failure is triggered by temperature
<dsimic>
I'd suggest that you don't throw your Rock 5A in trash, keep it for spare parts :)
<dsimic>
though, maybe I'm wrong and there's other option
<warpme>
yeah - especially reusing FCBGA1088 chip (SoC) might be handy spare part :-) I already see this long queue of hobbyst asking me for sell it to them as they want to resolder it as hobby :-))))))
<dsimic>
one man's trash is another man's treasure :)
<dsimic>
or s/man/person/ if we want to be gender neutral
<diederik>
ha, I guess I should've asked out loud whether cold vs warm boots makes a difference
<dsimic>
cold and warm literally :)
<diederik>
doesn't that mean that updating u-boot is back on the table as possible solution? It seems at least worth a try ...
<qschulz>
if the TPL propagates the proper info through ATAGS, a new U-Boot should be able to handle that and mark those as memory to not use (or just not add the area as available)
<warpme>
diederik : cold vs. warm reboot: no difference. Diff is in cold board vs. warm board: cold boots ok. warm: stops after some time
<diederik>
warpme: my "won't make a difference for this issue" was based on the assumption it always fails ... so (most of) u-boot things aren't even run
<diederik>
as that appears not the case, then a bug in u-boot *could* cause it, in which case a newer u-boot could fix it
<warpme>
yeah - indeed idea of "exclude bad mem reg. by dt" is an half solution: it will work only when dram training succeeded. Evident issue correlation with board temp gives me highest probability for hw defect - so i stopped checking sw. route. (additional args i had myself that this is not sw: my other 6 boars never had this; can't find any other report of this such issue; on this device also kernel gets mem paging ops after 1..2h of
<warpme>
operation).
<warpme>
i'm really curious how kernel will go with added mem reserv. in dt
naoki has quit [Quit: naoki]
psydroid has quit [Read error: Connection reset by peer]
psydroid has joined #linux-rockchip
ldevulder has quit [Quit: Leaving]
Daanct12 has quit [Quit: WeeChat 4.4.1]
Stat_headcrabed has joined #linux-rockchip
Stat_headcrabed has quit [Quit: Stat_headcrabed]
raster has joined #linux-rockchip
dsimic has quit [Ping timeout: 252 seconds]
dsimic has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
warpme has quit [Remote host closed the connection]
warpme has joined #linux-rockchip
raster has quit [Ping timeout: 246 seconds]
Bahhumbug is now known as Gerdesas
Gerdesas is now known as Bahhumbug
raster has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
mps has quit [Quit: leaving]
mps has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]