De volta ao dia de lançamento do AMD EPYC 7002 “Rome”, é importante destacar sobre como a AMD está trabalhando para retornar ao suporte ao BIOS/Coreboot de código aberto. Então, agora há mais confirmação de seu trabalho nessa direção. É que a AMD contrata para desenvolvimento do Coreboot. Além disso, está patrocinando a conferência de firmware de código aberto.
Edward Benyukhis, chefe de firmware de plataforma da AMD, divulgou publicamente no LinkedIn que ele está ‘procurando contratar alguém com experiência sólida em Coreboot e UEFI’. Portanto, se você tem experiência em Coreboot ou conhece alguém, consulte o LinkedIn para entrar em contato. Benyukhis.
AMD contrata para desenvolvimento do Coreboot e patrocina conferência de código aberto
Isso é empolgante e certamente digno de nota. Porém, também merece destaque que a AMD está agora patrocinando Conferência de Firmware de Código Aberto da próxima semana. A AMD se juntou a empresas como Amazon AWS, Arm, System76, TrustedFirmware.org e outras. Todas patrocinam esta conferência sobre Coreboot, LinuxBoot e projetos de firmware de código aberto relacionados.Tempos emocionantes pela frente, agora vamos apenas esperar que os problemas de middleware/licenciamento mencionados possam ser resolvidos em tempo hábil. Além das perspectivas de firmware de código aberto/UEFI/BIOS e Coreboot há muita coisa em relação ao servidor, como parte de iniciativas de computação segura. Além disso, há melhorias para usuários de desktop em geral, principalmente os defensores do Linux/FLOSS.
AMD prepara seu suporte à proteção de conteúdo HDCP 1.4 para Raven Ridge e mais recentes
Os desenvolvedores da AMD enviaram seus mais recentes patches de código-fonte aberto do Linux, fazendo o compartilhamento de drivers do kernel, para permitir o suporte a HDCP (High-bandwidth Digital Content Protection) para a versão 1.4 e mais recente.
Embora ver os patches de suporte ao HDCP para drivers gráficos de código aberto irrite muitos na comunidade, semelhante a outros drivers de código aberto que suportam HDCP, essa é apenas uma parte do quebra-cabeça da proteção de conteúdo. Somente esses patches não impõem restrições a usuários ou outras deficiências, mas se resumem principalmente a softwares proprietários que desejam utilizar os recursos HDCP no Linux. Os players de vídeo de código aberto e similares podem continuar desfrutando da aceleração de vídeo baseada em GPU ininterruptamente.
Portanto, embora haja muita oposição ao Gerenciamento de Direitos Digitais e HDCP pela comunidade de código-fonte aberto, ter o suporte no código do kernel do driver gráfico de código-fonte aberto não limita as liberdades atuais. Porém, por outro lado, para a longevidade do suporte ao driver Linux, essa é realmente uma boa notícia. Presumivelmente, esse trabalho recente de HDCP para o driver AMD Linux deve-se ao Google com seus Chromebooks.
Intel x AMD
O driver gráfico Linux de código aberto da Intel só começou a ver o HDCP funcionar há relativamente pouco tempo. Foi quando os engenheiros do Google estavam interessados ??no suporte da Intelno contexto do suporte do Chromebook. Agora, com a AMD colocando seu suporte em ordem, talvez isso signifique ter mais SoCs da AMD como Chromebooks. Obviamente, os desenvolvedores da AMD não investiriam neste módulo HDCP para o driver AMDGPU Linux. A menos que houvesse cliente com real necessidade. Assim, esta última adição ao HDCP possui mais de cinco mil linhas de novo código de driver.
Notícias Relacionadas
Por enquanto, essa implementação do HDCP 1.4 tem como alvo APUs Raven Ridge e mais recentes. Os patches estão atualmente organizados aqui e, dado que o tempo de atraso para o Linux 5.4 pode muito provavelmente acabar sendo material para o Linux 5.5 – tanto quanto os patches AMDGPU DRM estão preocupados com algum código miscel DRM já na fila para o próximo ciclo 5.4.
Para os puristas de software livre, mesmo que a funcionalidade padrão não sofra interferências, o código AMDGPU gera essa adição do módulo HDCP como uma nova opção DRM_AMD_DC_HDCP Kconfig. Isso permite que você continue construindo um kernel sem essa funcionalidade.
Via Phoronix
