On Fri, Jul 31, 2026 at 8:58 AM Daniel Lima <[email protected]> wrote: > > Subject: AMD BC-250 (Cyan Skillfish, gfx1013): can the VCN 2.0.3 power > domain be brought up? > > Hi, > > I'm working with an AMD BC-250 (ASRock mining blade, PCI 1002:13FE, Cyan > Skillfish / gfx1013, GC 10.1.3) on Fedora 44 with the stock 6.19.10 kernel. > Hardware video decode is unavailable, and I would like to ask whether that is > a > firmware limitation or just an untested configuration. > > The short version: in amdgpu_discovery_set_mm_ip_blocks(), UVD_HWIP > IP_VERSION(2, 0, 3) has an explicitly empty case, so neither vcn_v2_0_ip_block > nor jpeg_v2_0_ip_block is ever registered. Is that intentional because the > SMU 11.8 PMFW has no VCN power management, or is it simply that this ASIC was > never validated for video? > > What I measured, in case it is useful: > > - The IP discovery table does report the block. > /sys/class/drm/card1/device/ip_discovery/die/0/12/0/ gives > major.minor.rev = 2.0.3, harvest = 0x0, base_addr = 0x00007800. The > HARVEST_INFO table in the discovery binary is empty. > > - The whole UVD register aperture is unreadable. Through debugfs amdgpu_regs, > both segments return 0xFFFFFFFF: mmCC_UVD_HARVESTING, mmUVD_POWER_STATUS, > mmUVD_PGFSM_CONFIG, mmUVD_PGFSM_STATUS, mmUVD_STATUS, and the JPEG registers > in the 0x7800 segment. mmGRBM_STATUS through the same read path returns > 0x00003028, so the access method itself is fine. > > - Writing the value that vcn_v2_0_disable_static_power_gating() would write > with pg_flags == 0 (0x00055555 to mmUVD_PGFSM_CONFIG) is accepted but has no > effect; PGFSM_STATUS stays 0xFFFFFFFF. The PGFSM itself therefore appears to > sit inside the unpowered domain. > > - nv_common_early_init() sets cg_flags = 0 and pg_flags = 0 for GC 10.1.3, and > cyan_skillfish_ppt_funcs implements no .dpm_set_vcn_enable, so nothing ever > requests a VCN power-up. smu_v11_8_ppsmc.h has no VCN-related message, and > smu_v11_8_pmfw.h has no VCN feature bit; the clock level fields cover > LCLK / MP0CLK / FCLK / SOCCLK / DCEFCLK only. > > - From the platform firmware (AGESA!V9 RBNBDK-BL5 46.1.2.220426): the PMFW is > PSP directory entry type 0x08 / 0x12, version 0.58.7.1, and it contains the > string "AMD BC-250", so it looks board-specific. I could not find any VCN, > UVD or JPEG reference anywhere in the UEFI image. > > My questions: > > 1. Is IP_VERSION(2, 0, 3) deliberately unhandled because the PMFW on this SOC > cannot power up the VCN domain? > > 2. If a power-up path does exist -- an SMU message, or something the ABL / > AGESA is expected to do -- could you point at it? I am happy to test > patches. > > 3. Could the block be disabled in a way the harvest table would not reflect? > > I am not asking for support on an unsupported product. A factual answer either > way would help: the community documentation for this board currently > attributes > the missing decode to a signed-firmware restriction, which does not match what > I see -- the VCN 2.x ucode is present in linux-firmware and this ASIC uses > AMDGPU_FW_LOAD_DIRECT -- and I would rather correct that than let people keep > chasing it. >
VCN was not part of the product definition for BC-250. While the die may have the IP, it's possible there were manufacturing defects on it on particular chips. Some may work, some may not. Beyond that, like you said, I'm not sure any support was added to the PMFW or the vbios for this part because it wasn't part of the product definition. Without that, I don't think there is a way to power it up. Additionally, even if it were valid on a particular chip, there is no firmware for it. BC-250 requires signed firmwares and uses the standard PSP firmware loading mechanism. Alex
