03:46 <pinchartl> dsimic: when the following diff in rk3588-base.dtsi the reset button works as expected:

03:46 <pinchartl> - pinctrl-0 = <&tsadc_shut_org>;

03:46 <pinchartl> + pinctrl-0 = <&tsadc_shut>;

03:46 <pinchartl> I couldn't find a description of the difference between those two

03:57 <dsimic> pinchartl: oh, that's very interesting and I do remember some previous discussions about the same thing

03:58 <dsimic> I'd like to put that on my TODO list, for the additional research and testing, which may result in some patches... would you like to leave me yoru full namee and email address, so I can include proper tags for you in those possible patches?

03:59 <dsimic> here comes the mandatory clarification...

04:00 <dsimic> basically, your name and email addreess will/would become pretty much public that way

04:01 <dsimic> thus, providing that hinges on you being fine with your private data becoming public in the end

04:01 <dsimic> obviously, your email address will become pretty much public, so some spam may be expected in the future

04:01 <dsimic> though, I receive virtually zero spam, but YMMV

04:02 <dsimic> s/yoru/your/

04:03 <wens> dsimic: pinchartl is very much active and listed in the maintainers file :p

04:06 <pinchartl> dsimic: git log --author pinchart

04:06 <pinchartl> that will give you the information you asked for

04:06 <pinchartl> and more :-)

04:07 <dsimic> oh, sorry, I wasn't aware of the link bewteeen the IRC nick and the real identitiy

04:07 <dsimic> I'm having slight troubles grasping who's who in the IRC and Git domains :)

04:12 <dsimic> pinchartl: I'm pleased to meet you, Laurent :)

04:23 <dsimic> here are a couple of related messages/threads on the ML, for future reference:

04:23 <dsimic> - https://lore.kernel.org/linux-rockchip/20250124052611.3705-1-eagle.alexander923@gmail.com/

04:24 <dsimic> https://lore.kernel.org/linux-rockchip/20250130053849.4902-1-eagle.alexander923@gmail.com/

04:24 <dsimic> - https://lore.kernel.org/linux-rockchip/20250130053849.4902-1-eagle.alexander923@gmail.com/ *

08:13 <dsimic> wens: just checking, what happened with the instability issues? have you acquired a beefier 5 V PSU?

08:29 <wens> dsimic: not yet. I did realize that the Rock Pi boards have PD support and can do 12V PD instead of 5V. seems like a better choice

08:36 <dsimic> actually, not all of them can do that... some of them also require 3 A at 5 V, which is the reason why Radxa sells a custom PSU

08:38 <dsimic> using higher voltage is a better choice, of course, but it seems that board designers frequently opted for not having proper PD negotiation, relying instead on beefier 5 V PSUs and heavier-gauge USB cables

08:42 <dsimic> I was looking at some Radxa board schematic a few days ago (shame on me, I forgot which one :/), which was clearly capable of using 12 V as the input, it even was capable of performing PD negotiation, but it was left to negotiate 5 V only... very strange

10:36 <wens> at least the rock 3 and 5 series do seem to have the extra PD chip

12:51 <Ermine> sorry if this is the wrong chat, but what is the purpose of rockchip ISP thing?

12:57 <CounterPillow> processing the signal from cameras to turn into an actual image a human would want to see. Camera sensor output is quite raw and needs plenty of processing e.g. debayering and such

13:01 <dsimic> wens: yes, the ROCK 5B can do that, but it requires a bit of "prodding" in software to actually work, which should work well now both in U-Boot and in the kernel; I haven't tested all that well myself yet, though

13:01 <Ermine> CounterPillow: so I can connect a raw sensor to it and I get a v4l2 device?

13:04 <dsimic> Ermine: not really, because the ISP is just one of the steps in the processing pipeline, and the raw sensor connects to another IP that actually provides the required hardware interface

13:05 <dsimic> it's all rather convoluted, but also rather straightforward, no matter how contradictory it may sound :)

13:06 <Ermine> huh...

13:10 <dsimic> to clarify a bit, IP means "intellectual property block" in this context

13:10 <Ermine> I understood

13:10 <Ermine> that's quite common abbreviation in hardware stuff

13:11 <dsimic> indeed

13:33 <pinchartl> dsimic: I've replied to the mail thread with a precise description

13:34 <pinchartl> Ermine: #linux-media on OFTC for anything V4L2-related, but for this topic #libcamera on OFTC may be a better pick

13:35 <pinchartl> as you'll need to involve the ISP eventually, libcamera is the way to go

13:35 <pinchartl> there's quite a lot of work still to be done, but the good news is that we're starting to look at camera support for the RK3588

13:36 <Ermine> \o/

13:37 <Ermine> thanks for the links!

13:41 <_walter_32> I've found a "security" issue in MaskROM when secure boot efuses are not burnt. There's the option to dump the eMMC contents, but you can't dump past the first 32MB, it's a "security" feature that is baked into MaskROM, but it looks like you can trick MaskROM to get past that limitation. Does anyone know where I could report this?

13:42 <_walter_32> (I'm talking about RK3399 device, but who knows, it might be an issue also on newer devices)

13:44 <phh> i don't understand. if euses aren't burnt, you can chainload any bootloader that will happily dump all content of emmc?

13:45 <phh> efuses*

13:48 <_walter_32> how do you chainload? do you mean "overwrite" the bootloader?

13:50 <_walter_32> That "you can't dump anything past 32MB" is an attempt at a security feature that works for non-secureboot devices, but it has a mistake that I'm thinking could/should be fixed.

13:53 <phh> you write uboot in ram and you ask maskrom to jump to it?

13:54 <phh> you're clearly more knowledgeable on the maskrom than i am, so there must be something i'm missing

13:55 <CounterPillow> that doesn't sound like a security issue considering you can just load arbitrary code at that point that does the same thing lol

13:59 <_walter_32> I see. The thing is, I've mistakenly used a signed bootloader on a device without burnt efuses, and it gave me the ability to dump the full eMMC. On the same device, if you load an unsigned bootloader, you can't dump the full eMMC, well, actually you can, but you get 0xCC past the first 32MB.