Hi Alexey, On 2024-05-31 13:44, Alexey Charkov wrote: > Hi Jonas, > > On Fri, May 31, 2024 at 3:27 PM Jonas Karlman <jonas@xxxxxxxxx> wrote: >> >> Hi Alexey and Dragan, >> >> On 2024-05-30 21:31, Dragan Simic wrote: >>> Hello Alexey, >>> >> >> [snip] >> >>>>>>> That way we'll have no roadblocks if, at some point, we end up with >>>>>>> having >>>>>>> different OPPs defined for the RK3588 and the RK3588S variants. Or >>>>>>> maybe >>>>>>> even for the RK3582, which we don't know much about yet. >>>>>> >>>>>> Guess we'll deal with that one once we stumble upon an actual RK3582 >>>>>> board out in the wild and heading to the mainline kernel tree :) >>>>> >>>>> Of course, that was just an example for the future use. >>>> >>>> In fact, I've just discovered that Radxa has recently released Rock 5C >>>> Lite which is based on RK3582, and starts at just $29 for the 1GB >>>> version, making it interesting for tinkering. Especially given that >>>> its GPU, one of the big-core clusters and one of the VPU cores seem to >>>> be disabled in software (u-boot) rather than in hardware, which means >>>> there is some chance that a particular SoC specimen would actually >>>> have them in a working condition and possible to re-enable at no cost. >>>> Ordered myself one to investigate :) >>> >>> Yes, I also saw the RK3582-based ROCK 5C Lite a couple of days ago. :) >>> It seems that the disabled IP blocks are detected as defective during >>> the manufacturing, which means that they might work correctly, or might >>> actually misbehave. It seems similar to the way old three-core AMD >>> Phenom II CPUs could sometimes be made quad-core. >>> >> >> I can confirm that the RK3582 include ip-state in OTP indicating >> unusable cores, any unusable cpu core cannot be taken online and stalls >> Linux kernel a few extra seconds during boot. >> >> Started working on a patch for U-Boot to remove any broken cpu core >> and/or cluster nodes, similar to what vendor U-Boot does, adopted to >> work with a mainline DT for RK3588. > > Superb - it's great to have a patch for it already, thank you for working on it! > >> On one of my ROCK 5C Lite board one of the cpu cores is unusable, U-Boot >> removes the related cpu cluster nodes. On another ROCK 5C Lite board one >> rkvdec core is only marked unusable and all cpu cores can be taken >> online, U-Boot does nothing in this case. Guessing we should apply >> similar policy as vendor U-Boot and disable cores anyway. > > Is there any misbehavior / instability if you just keep all the > unmarked cores online? I will run some tests during the weekend and get back with results later. > > I think from an end-user perspective it would be better to just enable > everything that works, as the reason to unconditionally disable some > IP blocks even when they are "good" is quite likely not a technical > one but rather a marketing one. It's hard to justify selling chips > with different sets of working IP blocks under the same label and the > same price, making it easier to just trim them all to a lowest common > denominator. On the other hand, once a person has already bought a > device where some IP blocks work even if they are not supposed to, why > not make use of them? It costs nothing, hurts noone... I agree, it is probably more related to marketing, licensing and/or what is tested. Vendor U-Boot apply following logic/policy for rk3582 (and rk3583). RK3582 policy: - always remove gpu - always remove both rkvdec cores - remove bad rkvenc core, if both are normal, remove rkvenc1 anyway RK3583 policy: - always keep gpu - remove bad rkvdec core, if both are normal, remove rkvdec1 anyway - remove bad rkvenc core, if both are normal, remove rkvenc1 anyway CPU core policy: - remove both cores within a cluster having a bad core - if core4~7 are all normal, remove core6 and core7 anyway Regards, Jonas > > Best regards, > Alexey
