Re: AMD BC-250 (Cyan Skillfish, gfx1013): can the VCN 2.0.3 power domain be brought up?

On Fri, Jul 31, 2026 at 8:58=E2=80=AFAM 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 kerne=
l.
> Hardware video decode is unavailable, and I would like to ask whether tha=
t 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 th=
e
> 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 =3D 2.0.3, harvest =3D 0x0, base_addr =3D 0x00007800. T=
he
>   HARVEST_INFO table in the discovery binary is empty.
>
> - The whole UVD register aperture is unreadable. Through debugfs amdgpu_r=
egs,
>   both segments return 0xFFFFFFFF: mmCC_UVD_HARVESTING, mmUVD_POWER_STATU=
S,
>   mmUVD_PGFSM_CONFIG, mmUVD_PGFSM_STATUS, mmUVD_STATUS, and the JPEG regi=
sters
>   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 wri=
te
>   with pg_flags =3D=3D 0 (0x00055555 to mmUVD_PGFSM_CONFIG) is accepted b=
ut has no
>   effect; PGFSM_STATUS stays 0xFFFFFFFF. The PGFSM itself therefore appea=
rs to
>   sit inside the unpowered domain.
>
> - nv_common_early_init() sets cg_flags =3D 0 and pg_flags =3D 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 PMF=
W 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 V=
CN,
>   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 refle=
ct?
>
> I am not asking for support on an unsupported product. A factual answer e=
ither
> way would help: the community documentation for this board currently attr=
ibutes
> 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 use=
s
> 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