<naoki>
<chewitt> naoki that's a shame, means I can't add the driver to LE images <- "LE" == "LibreELEC"?
<naoki>
Can someone tell me which OSS projects won't accept drivers that haven't been merged into mainline, such as the AIC8800, and which chips are preferable?
tlwoerner has joined #linux-rockchip
hexdump01 has quit [Ping timeout: 256 seconds]
hexdump01 has joined #linux-rockchip
ungeskriptet has quit [Remote host closed the connection]
<chewitt>
distro policies for drivers are quite variable
<chewitt>
most will allow anything as drivers are in a separate package and the user contributing the package only cares that it compiles and 'works'
<chewitt>
if it compiles, must be good, right? :)
<chewitt>
as a maintainer, I want adding new hardware (boards) to be a low-friction exercise
<chewitt>
if you picked a broadcom or realtek chip that's already supported upstream (or in the process of being supported) the worst I need to do is cherry-pick some patches
<wens>
naoki: curiously these dev board vendors don't provide wireless modules with mediatek chipsets
<chewitt>
and those patches are dropped within 1-2 kernel cycles so I have no technical debt
<wens>
but they shouldn't be hard to find. we use them extensively, at least the PCIe ones, on Chromebooks
<chewitt>
the moment you pick some cheap downstream-only chip, I am forced to sign-up to a pile of maintenance effort
<chewitt>
the source is mostly ancient, hacked for Android vendor kernels, has random firmware requirements
<wens>
Realtek SDIO support lacks behind USB and PCIe though
<chewitt>
kernel bumps will frequently cause breakage .. requiring me to create patches, which I cannot upstream anywhere
<chewitt>
so I accumulate ever-more technical debt on that driver over time
<chewitt>
so LE middle-fingers that issue; we advise users to vote with their wallet and avoid boards that require downstream drivers
<chewitt>
(as we won't add the drivers)
<chewitt>
we are probably towards the militant end of the scale, but we have a small all-volunteer staff and fixing bad drivers isn't fun
<wens>
wanted to test the new vicap drivers, but haven't figured out my imx219 camera module yet
<chewitt>
to be fair, broadcom and realtek support isn't perfect, they are not guaranteed bug-free etc.
<chewitt>
but the issues that crop up are normally resolved long before I have users flagging them, so it's simple to cherry-pick a patch from a list that will drop in the next kernel bump
<chewitt>
it's quite rare that I have to engage with developers and report issues
<naoki>
wens: I don't understand why development boards don't use MediaTek Wi-Fi chips.
<naoki>
By the way, I personally prefer MediaTek over Realtek and Broadcom, what do you guys recommend?
<wens>
probably a volume thing?
raster has joined #linux-rockchip
<CounterPillow>
I prefer Intel Wi-Fi :P
veremitz has quit [Server closed connection]
veremitz has joined #linux-rockchip
<walter>
Does anyone know why I would automatically see "loader" in RKUSB mode instead of "maskrom", after pressing the reset button? It's automagically loaded from the emmc and I don't know wny. The UART shows that when holding the reset button button, I first get to see uboot, then RKUSB.
<CounterPillow>
presumably maskrom loads a loader from eMMC
stikonas has joined #linux-rockchip
<CounterPillow>
Like, maskrom doesn't know what it's loading, it just sees the idblock and jumps to it
<CounterPillow>
if that happens to be a u-boot that drops to rockusb loader mode then that's what you get
<diederik>
chewitt: FWIW I wish more projects would have such a policy as LE :)
stikonas has quit [Remote host closed the connection]
<walter>
I'm still waiting to get the schematic to see where the reset button is connected, but I have a hunch that this U-Boot message is the problem: "download key pressed... entering download mode..."
<qschulz>
walter: it is
<qschulz>
this means it's the Recovery button, which is specific to vendor U-Boot and not the BootROM
<diederik>
I've been wanting to know what I'd need to enable to actually see that message
<qschulz>
diederik: upstream, you would need TPL/SPL_ADC enabled as well as CONFIG_ROCKCHIP_BOOT_MODE_REG being non-zero
<qschulz>
as well as CONFIG_SARADC_ROCKCHIP
<qschulz>
the logic is in arch/arm/mach-rockchip/boot_mode.c
<diederik>
qschulz: thanks :) Both are not enabled
<diederik>
Correction: Neither of the 4 are enabled
<walter>
thanks qschulz
<qschulz>
walter: which device is it again?
<walter>
It's an RK3399 board
<qschulz>
walter: then it doesn't have the neat boot medium selection for the BootROM the new SoCs have (like on RK3588)
<qschulz>
so something needs to cut the data lines or clock line to all bootable medium to be able to enter maskrom mode
<walter>
I've read about the new SOCs.
<qschulz>
on our RK3399 module, we cut the clock line for the eMMC and put the NOR flash HOLD# line low
<qschulz>
so I assume you could simply ground those lines if your board doesn't have a button/jumper that allows to do it
<walter>
Yes, grounding works, that's how I recovered the device when I've butrchred the emmc bootloader. Question, how can one get back into maskrom mode if you are already in U-boot? Cause that is what it's happening here, I think. And it's not what I want, because this allows you to dump the emmc without a signed loader..
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<qschulz>
walter: look how rockchip_dnl_mode_check is implemented in arch/arm/mach-rockchip/boot_mode.c
<qschulz>
but I'm not sure to understand the question, you ask how to do something because you don't want to do it?
<walter>
No, currently, if I hold that reset button while powering on the device, I get into MaskROM mode, and in `rkdeveloptool` I see `loader`. AKA: the boot is poorly implemented and you can get around needing a signed loader to flash or dump the eMMC.
<qschulz>
walter: just don't build arch/arm/mach-rockchip/boot_mode.c when you're building for secure boot
<qschulz>
or have CONFIG_ROCKCHIP_BOOT_MODE_REG=0 in your defconfig when doing secure boot
<walter>
Nice, thank you very much! This might be it.
<chewitt>
but for normal client devices iwlwifi is good, although the amount of firmware required is a little annoying
<chewitt>
I know distros like openwrt support all kinds of boards, but really I wonder how many sbc boards with 1x ethernet port are really used
<chewitt>
really you want a 'router' board with multiple ethernet sockets, and those mostly use realtek chips, from what I see
walter has quit [Ping timeout: 258 seconds]
veremitz has quit [Ping timeout: 256 seconds]
hexdump01 has quit [Ping timeout: 256 seconds]
hexdump01 has joined #linux-rockchip
dsimic has quit [Ping timeout: 256 seconds]
dsimic has joined #linux-rockchip
veremitz has joined #linux-rockchip
walter has joined #linux-rockchip
ldevulder_ has joined #linux-rockchip
Hypfer1 has joined #linux-rockchip
tlwoerner_ has joined #linux-rockchip
Hypfer has quit [Ping timeout: 244 seconds]
ldevulder has quit [Ping timeout: 244 seconds]
Hypfer1 is now known as Hypfer
necessarypinch2 has joined #linux-rockchip
Dex2x has joined #linux-rockchip
chewitt_ has joined #linux-rockchip
tlwoerner__ has joined #linux-rockchip
ldevulder__ has joined #linux-rockchip
ldevulder_ has quit [Read error: Connection reset by peer]
necessarypinch2 has quit [Read error: Connection reset by peer]
Dex2x has quit [Read error: Connection reset by peer]
tlwoerner_ has quit [Ping timeout: 256 seconds]
Hypfer has quit [Ping timeout: 256 seconds]
Hypfer has joined #linux-rockchip
cbeznea_ has quit [*.net *.split]
raster has quit [*.net *.split]
chewitt has quit [*.net *.split]
necessarypinch has quit [*.net *.split]
tlwoerner has quit [*.net *.split]
naoki has quit [*.net *.split]
macromorgan has quit [*.net *.split]
rgolledge has quit [*.net *.split]
urja has quit [*.net *.split]
Dex_2x has quit [*.net *.split]
s1b1 has quit [*.net *.split]
tortoise has quit [*.net *.split]
adadad has quit [*.net *.split]
cbeznea_ has joined #linux-rockchip
rgolledge has joined #linux-rockchip
necessarypinch has joined #linux-rockchip
s1b1 has joined #linux-rockchip
tortoise has joined #linux-rockchip
macromorgan has joined #linux-rockchip
adadad has joined #linux-rockchip
raster has joined #linux-rockchip
urja has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Dex2x has joined #linux-rockchip
stikonas has joined #linux-rockchip
warpme has joined #linux-rockchip
hexdump01 has quit [Ping timeout: 260 seconds]
hexdump01 has joined #linux-rockchip
Hypfer9 has joined #linux-rockchip
_walter_32 has joined #linux-rockchip
Hypfer has quit [Read error: Connection reset by peer]
Hypfer9 is now known as Hypfer
walter has quit [Read error: Connection reset by peer]
_walter_32 has quit [Quit: Konversation terminated!]
_walter_32 has joined #linux-rockchip
_walter_32 has quit [Client Quit]
ldevulder__ is now known as ldevulder
walter has joined #linux-rockchip
<Danct12>
curious but is it possible to blow an efuse on rk3566?
<Danct12>
secure boot efuse
<qschulz>
if they are secure boot, they likely are only accessible from the secure world
<CounterPillow>
Danct12: that sort of info is under NDA iirc
<qschulz>
which means before TF-A is started (or in TF-A/OP-TEE)
<Ermine>
does it mean that you can't have secure boot without rockchip blobs?
<Danct12>
oh, so i guess there must be a firmware that runs before TF-A, that does the efuse blowing?
<CounterPillow>
Ermine: no that's not what that means
<Danct12>
like, read off a block offset for the key, then blow up and reset the board
<qschulz>
Ermine: you for sure can without blobs, we do this on PX30 but like CounterPillow said, under NDA
<Danct12>
i know rockchip has their own tools on a pc to do that, but i mean, doing it all on the device itself
<qschulz>
Danct12: you can, we do it but I cannot tell you how :/
<qschulz>
I've heard some people RE the secure boot on RK3588 I believe, don't know if it's public yet though
<walter>
Danct12: what are you trying to achieve? make a secureboot device skip the "secure" part of the boot? I think that you can partially do that by using the public tools, you'll only need to set `SEC=0` in your RKTRUST file. -- that is if you have the original key.
cbeznea_ has left #linux-rockchip [Leaving]
ldevulder has quit [Quit: Leaving]
tlwoerner__ has quit [Quit: Leaving]
tlwoerner has joined #linux-rockchip
anarsoul|2 has quit [Ping timeout: 248 seconds]
chewitt_ is now known as chewitt
<wens>
anyone also getting "rtc-hym8563 5-0051: probe with driver rtc-hym8563 failed with error -110" on Rock 3A?
<CounterPillow>
do you have an RTC battery attached?
phh has quit [Server closed connection]
phh has joined #linux-rockchip
<wens>
I just added one, and it still gives the error
<wens>
or maybe the polarity is reversed :|
<wens>
shouldn't matter since it can also get power from vcc3v3?
<diederik>
chewitt: At a first glance that seems quite good. You've identified the wrong/missing pieces I found too in the dtsi and I was going to ask for help for the non-dtsi things which you already have.
f_ has quit [Ping timeout: 248 seconds]
<diederik>
detlev's "media: rkvdec: Add H264 support for the VDPU381 variant" patch also creates "rkvdec-vdpu381-regs.h" and we may need to do sth similar for "rkvdec-vdpu346-regs.h" as that appears to contain differences between vdec from rk3588 and rk3568. I want/need to do further research into that though
<diederik>
(and I'm inclined to think 'RKVDEC_1080P_PIXELS' should be '(1920 * 1088)')
<diederik>
RK3568 TRM Part2 chapter 10 (and especially para 10.4.3) was the reason I thought I could make a RFC patch after all
<diederik>
RK3588 TRM Part1 chapter 5 (and especially para 5.4.3) was used to compare VDPU346 vs VDPU381
<diederik>
I guess you found that too given 'cache' was added to the dts
sjoerd43 has joined #linux-rockchip
sjoerd4 has quit [Read error: Connection reset by peer]
sjoerd43 is now known as sjoerd4
f_ has joined #linux-rockchip
raster has quit [Quit: Gettin' stinky!]
<diederik>
chewitt: You should probably add that this is 'only' the h264+h265 part of VDPU346 (IIRC detlev did say that in their patch)
<diederik>
VDPU346 also does VP9 (and there is a register value for AVS2), while VDPU381 does VP9 and AVS2
<diederik>
(Config Register Linked List Pointer mode; 5.4.4.1.2 in RK3588 TRM Part1 mentions 'VDPU346 Video decoder support link table mode' instead of VDPU381 :-P)
<diederik>
mpeg2 support is part of VDPU121 (h263 and mpeg 1/2/4 to be exact) and that is (likely) the same between RK3568 and RK3588 (they have the same 'name')
<diederik>
The JPEG decoder (VDPU720) and the JPEG encoder (VEPU121) should also be the same between RK3568 and RK3588
<diederik>
It (now) seems pointless for me to (still) make a RFC patch :) so I won't.
<diederik>
hmm VDPU121 on RK3568 doesn't have a 'cache', while on RK3588 it does ... (so same name != same functionality :-/)
s1b1 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
<diederik>
and VEPU121 on RK3568 has 1 core, while on RK3588 it has 5 cores
cbeznea has quit [Ping timeout: 258 seconds]
<CounterPillow>
it's just 5 copypaste instances of Hantro
<diederik>
I wonder if the sequence of the 'regs' should be "link" "function" "cache" so the addresses are sorted (minor nit; especially as for VDPU720 it's "function" "link" ...)
sL1pKn07 has quit [Server closed connection]
sL1pKn07 has joined #linux-rockchip
<CounterPillow>
Changing order of regs in an existing binding is generally a bad idea. Implementations may rely on the order.
s1b1 has joined #linux-rockchip
<diederik>
thanks for that :)
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
stikonas has quit [Quit: Konversation terminated!]