DC-IRC has quit [Remote host closed the connection]
DC-IRC has joined #armbian-broadcom
<DC-IRC>
<microlinux> Sorry that I didn't follow your testing! I was just curious about the topic. I don't own a pi4 since 6 months or so, so I was interested to know the current status @clever___
<DC-IRC>
<clever___> i'm also surprised by the numbers i saw
<DC-IRC>
<clever___> will need more testing to figure out why its wonky
<DC-IRC>
<microlinux> At some point, rpi will have to look out for a different soc vendor.
<DC-IRC>
<clever___> probably
<DC-IRC>
<clever___> the big thing i see backing rpi, is the large community, and pre-existing userbase
<DC-IRC>
<microlinux> Indeed
<DC-IRC>
<microlinux> Imagine.. if rpi decides to make it's own chip, license arm and use mali(panfrost)
<DC-IRC>
<microlinux> It's quite difficult
<DC-IRC>
<microlinux> But would be lovely
<DC-IRC>
<clever___> the rp2040 does show that they are testing the waters on making custom silicon
<DC-IRC>
<microlinux> Indeed
<DC-IRC>
<microlinux> I jumped outside rpi, but if they do something like that. I would board that ship again, even if it's not that powerful
<DC-IRC>
<clever___> with the work ive been doing, you can now boot linux on the pi2 and pi3, with fully open firmware
<DC-IRC>
<clever___> and the pi3 can boot from usb
<DC-IRC>
<clever___> but you lose h264 encode, hdmi, and camera
<DC-IRC>
<clever___> but you lose h264 encode, hdmi/dsi, and camera
<DC-IRC>
<clever___> it doesnt fix the lack of hw docs, but it does make the firmware stack something anybody can edit
<DC-IRC>
<microlinux> Indeed. I think rpi have the numbers to make it's own chip tbh. I mean, the microarchs are just a license, you need to hire some engineers and the fab quota. It's not impossible to think something like that.
<DC-IRC>
<clever___> the biggest problem with RPF switching SoC (existing or custom), is that the entire software stack goes in the trash
<DC-IRC>
<clever___> and they have to build that up from nothing again
<DC-IRC>
<microlinux> Currently, based on the info I have, broadcom it's not interested on this market anymore
<DC-IRC>
<clever___> there is already confusion about people thinking the rp2040 is as capable as the rpi4
<DC-IRC>
<clever___> because they are both raspberry pi's
<DC-IRC>
<clever___> and they think, if the rpi4 can do hdmi, why cant the rp2040 also do hdmi?
<DC-IRC>
<microlinux> So, that's something they will have to decide anyway
<DC-IRC>
<clever___> throw a 2nd SoC vendor in, and chaos begins
<DC-IRC>
<microlinux> Well, contracts are contracts. I think if they go solo, that can be acceptable to broadcom
<DC-IRC>
<microlinux> At the end, it's broadcom not offering any option
<DC-IRC>
<microlinux> If broadcom had a replacement for rpi5, they would deliver, and as today, they didn't.
<DC-IRC>
<microlinux> The only soc I know.. would be enough
<DC-IRC>
<microlinux> Av1
<DC-IRC>
<microlinux> Better lithography
<DC-IRC>
<microlinux> Decent enough
<DC-IRC>
<microlinux> 4x cortex a72 are good enough
<DC-IRC>
<clever___> there are other things that can be done, to make a better soc with very little changes, just the bcm2711 b0 vs c0
<DC-IRC>
<microlinux> One thing I praised regarding rpi4 was the cpu power despite its lack of efficiency
<DC-IRC>
<clever___> from what ive heard, all they did, was change a setting in the RTL synthesizer, to automate clock gating
<DC-IRC>
<clever___> so if the inputs to a hw block are constant, the clock is gated, and the block is effectively running at 0hz
<DC-IRC>
<clever___> thats effectively under-clocking every hw block, to exactly the right number of clock cycles it needs
<DC-IRC>
<microlinux> Sorry, which clock its running at 0 hz, I lost you.
<DC-IRC>
<clever___> lets say there is an spi block in the soc, that has a 100mhz ref-clk going into it
<DC-IRC>
<clever___> when all spi transfers complete, that clock is just turned off
<DC-IRC>
<microlinux> Okay
<DC-IRC>
<clever___> so the spi block is effectively running at 0hz, until you do a transfer
<DC-IRC>
<clever___> and now spi isnt wasting energy on every clock cycle
<DC-IRC>
<clever___> repeat that, in every hw block, and you have the bcm2711c0, which uses less power then a b0 at idle
<DC-IRC>
<microlinux> That would indeed increase efficiency. I admire your dedication to understand rpi hw. I would love such dedication on rk or aml. I have no expertise on low level hw stuff as you do, less on rpi platforms.
<DC-IRC>
<microlinux> I will receive an opi3b(I hate the name, super confusing). It's an rk3566.
<DC-IRC>
<microlinux> Quite efficient soc.
<DC-IRC>
<microlinux> But, to get any real usecase for mipi csi, legacy rk....
<DC-IRC>
<microlinux> Until enc get support on mainline
<DC-IRC>
<clever___> for the rpi, there are ~3 hardware blocks involved in camera stuff
<DC-IRC>
<clever___> the unicam deals with csi->dram, dropping raw bayer into the ram
<DC-IRC>
<clever___> the `ISP` deals with computing stats to help the automatic whitebalance
<DC-IRC>
<clever___> doing software whitebalance
<DC-IRC>
<clever___> lens shading
<DC-IRC>
<clever___> and bayer->yuv conversions
<DC-IRC>
<microlinux> I am content creator, rk3588 on rk linux was the fucking first time I have vpu enc/dec on software like OBS
<DC-IRC>
<clever___> the `VCE` then handles yuv->h264 compression
<DC-IRC>
<microlinux> On arm linux
<DC-IRC>
<clever___> and the VPU has the drivers for the ISP and VCE
<DC-IRC>
<microlinux> It's super annoying to not have that on mainline on any sbc, neither rpi
<DC-IRC>
<microlinux> I mostly use arm sbcs as desktop, so, my target It's a niche on its own
<DC-IRC>
<clever___> that use-case fits the current state of the open firmware a bit better
<DC-IRC>
<microlinux> You know what, you should try big cotton
<DC-IRC>
<clever___> i'm missing 2 big things that you may want though