jaganteki has quit [Remote host closed the connection]
paulk-leonov has joined #linux-rockchip
paulk-leonov has quit [Excess Flood]
paulk-leonov has joined #linux-rockchip
matthias_bgg has quit [Remote host closed the connection]
matthias_bgg has joined #linux-rockchip
matthias_bgg has quit [Remote host closed the connection]
matthias_bgg has joined #linux-rockchip
matthias_bgg has quit [Quit: Leaving]
matthias_bgg has joined #linux-rockchip
mps has quit [Ping timeout: 256 seconds]
maze-BUG has joined #linux-rockchip
mps has joined #linux-rockchip
maze-BUG1 has joined #linux-rockchip
maze-BUG has quit [Ping timeout: 260 seconds]
maze-BUG1 is now known as maze-BUG
<nomis>
robmur01: have you ever encountered an inverted activity led on the ethernet port?
<robmur01>
that's pretty much a "yes by definition" - IME no two ethernet devices have a consistent way of encoding link state vs. activity via LEDs anyway :P
<robmur01>
I think my new hub actually uses "default on and blink off" vs. "default off and blink on" to reflect 1000M vs. 100M
<nomis>
robmur01: ah, ok. Then I won't care about that for now.
<robmur01>
*switch
<nomis>
Just weird to have a led there with no cable plugged in...
<robmur01>
first last and only time I bought a hub was, gulp, 20 years ago now
<robmur01>
sometimes if the LEDs are driven automatically off the phy the behaviour can be tweaked; if they're GPIOs then obviously you can play with active-high/active-low and maybe the triggers too
<nomis>
I could decouple the LED from the phy and then see if there is a matching trigger.
<robmur01>
is your box using an external gigabit phy or the SoC-internal 100M one?
<nomis>
robmur01: I'd guess the internal one. The device tree refers to it as ethernet@ff550000
<nomis>
compatible = "rockchip,rk3328-gmac"
<nomis>
this block refers to the LEDs via pinmux setup, specifically fephyled-rxm1, which sets the RK_PD1 pin to the alternate function 2.
<robmur01>
well, the two MACs are identical, but ff55 is indeed the one wired to the internal phy
<nomis>
(i.e. not a plain GPIO)
<robmur01>
yeah, the link and data LEDs look to be functions of GPIO2_D0 and GPIO2_D1 respectively
<tuxd3v>
robmur01, 4GB DDR4...doesn't cut mustard, we are expecting 8GB now
mayab76 has joined #linux-rockchip
<robmur01>
tuxd3v: 8GB in a router? Just how big are your NAT tables? :P
<tuxd3v>
WEl I was expecting it not in a router :)
<tuxd3v>
WEl -> Well
<robmur01>
but yeah, I hope RK start actually supporting a >32-bit memory map
<JPEW>
Does anyone know about the TLB on the rockchip processors (RK3399 and RK3288)?
<robmur01>
nomis: so I guess you can either claim both functions via pinctrl and let the phy do its thing, or use them in GPIO mode to do whatever you want :)
<robmur01>
JPEW: by "the TLB" do you mean the CPU MMUs?
<JPEW>
robmur01: Yes
<JPEW>
Specifically how it handles huge pages
<nomis>
robmur01: yeah, I'll keep it as is for now. Not really worth the bother.
<JPEW>
robmur01: Right :) Specifically, I've noticed a case where using transparent huge pages is significantly slower for a memory copy when a huge page is involved
<JPEW>
robmur01: with transparent huge pages "always": perf bench mem memcpy -s 1GB -> 2.947983 GB/sec
<JPEW>
robmur01: transparent huge pages set to "advise": perf bench mem memcpy -s 1GB -> 7.272463 GB/sec
<robmur01>
certainly quite a few of our cores can't hold 2MB entries in the closest level of TLB, so in theory if you have really good locality then 4K might in principle lead to quicker hits
<robmur01>
try using `perf stat` to compare TLB and pagetable related events
<JPEW>
robmur01: Sorry, I'm new to 'perf stat'. I tried 'perf stat -d perf bench mem memcpy -s 1GB'. The only apparently interesting stat is L1-dcache-loads. madvise = 611.001 M/sec, always = 367.896 M/sec
<robmur01>
yeah, you probably want to target some specific events (via `-e ...`) - see `perf list` for what's available
<robmur01>
also try to avoid doing it on RK3399 because perf on big.LITTLE is a bloody nightmare ;)
<JPEW>
heh, I usually just disable one set of cores when profiling
mayab76 has quit [Remote host closed the connection]
eballetbo has quit [Excess Flood]
eballetbo has joined #linux-rockchip
ElBarto has joined #linux-rockchip
<ElBarto>
Hello
<ElBarto>
is it ok to talk about mainline u-boot here ?
klokken has quit [Ping timeout: 240 seconds]
<robmur01>
ElBarto: it's been known to happen ;)
<ElBarto>
cool :)
<ElBarto>
so, with u-boot 2019.10 I see weird memory issues
<ElBarto>
but it looks like that since the rk3328 sdram driver was merged with the px30 one the issue reappears
klokken has joined #linux-rockchip
<ElBarto>
and I don't really know how all this works
klokken has quit [Ping timeout: 240 seconds]
klokken has joined #linux-rockchip
<robmur01>
me neither, and the DRAM drivers look a bit too complex to make guesses about. FWIW my (LPDDR3) 3328 box has had 2020.01-rc4 on it since whenever that was and has been fine, so whatever's up must be fairly board-dependent
<ElBarto>
mhm no it seems that the changes are their in the phy_px30 driver so it's something else ...
<ElBarto>
I'm using rock64 fyi
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
vicencb has joined #linux-rockchip
<inode>
ElBarto: what kind of memory issues do you experience?
<ElBarto>
inode: weird panics in FreeBSD when accessing some memory (it's always different)
<ElBarto>
I don't see those with v2019.10+series=134525 and mainline atf v2.1
<robmur01>
JPEW: curious indeed... not sure what to make of the ~25% increase in instruction count :/ Just kicked off a rebuild of my board's kernel with THP enabled to see if I can repro
tuxd3v has quit [Quit: Leaving]
return0e has quit [Read error: Connection reset by peer]