Hello Dragan, On 2024-05-31 23:24, Dragan Simic wrote: > Hello Jonas, > > On 2024-05-31 13:27, Jonas Karlman wrote: >> On 2024-05-30 21:31, Dragan Simic wrote: >> [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. > > Thanks for this confirmation! > >> 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. > > Nice, thanks for working on that. :) > >> 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. > > Just checking, you're referring to disabling the rkvdec core only, > for the latter case? No, the vendor U-Boot will remove cluster2 if no cpu core is bad. RK3582 policy: - always remove gpu node - always remove both rkvdec nodes - remove bad rkvenc node, if both are normal, remove rkvenc1 anyway RK3583 policy: - remove bad rkvdec node, if both are normal, remove rkvdec1 anyway - remove bad rkvenc node, 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 > >> Following commit contains early work-in-progress and some debug output. >> >> https://github.com/Kwiboo/u-boot-rockchip/commit/8cdf606e616baa36751f3b4adcfaefc781126c8c >> >> Booting ROCK 5C Lite boards using U-Boot generic-rk3588_defconfig: >> >> ROCK 5C Lite v1.1 (RK3582 with 1 bad cpu core): >> >> cpu-code: 3582 >> cpu-version: 08 10 >> data: fe 21 >> package: 11 >> specification: 01 >> ip-state: 10 00 00 >> bad-state: cpu core 4 >> >> ROCK 5C Lite v1.1 (RK3582 with 1 bad rkvdec core): >> >> cpu-code: 3582 >> cpu-version: 08 00 >> data: fe 21 >> package: 11 >> specification: 01 >> ip-state: 00 80 00 >> bad-state: rkvdec core 1 > > Thanks again for these nice details!
