Atrasos causados pela falta de componentes eletrônicos

Como mencionamos anteriormente, ainda somos vítimas das dificuldades da cadeia de suprimentos da indústria eletrônica. Em julho, informamos que “98% dos mais de 2000 componentes estão agora assegurados e serão entregues dentro do prazo”. A caça ainda está em andamento para os quarenta componentes restantes, e encontrá-los é crucial para não perder o prazo de outubro”. Alguns dos componentes de gerenciamento de energia estão atualmente indisponíveis, então o projetista eletrônico teve que pesquisar substitutos. Em breve, publicaremos o projeto de PCB atualizado rcom todos os novos componentes. A fábrica ainda não recebeu todos os componentes necessários que já encomendamos, e ainda não foi possível encontrar até agora em nenhum lugar do mercado. Em particular, estamos enfrentando problemas para obter o conector HDMI (número de peça 2041481-1) que caberia dentro do chassi do notebook Eclipse. Se você puder nos ajudar a encontrar tal conector, entre em contato conosco. Estamos procurando urgentemente por 3 unidades deste conector para os 3 protótipos. Além disso, também estamos procurando uma solução para a produção de lotes maiores.

Aumento inesperado do preço dos protótipos: 1000 euros

Estamos muito felizes com a generosa participação de todos os doadores que permitiram que a campanha do protótipo ultrapassasse 90% da meta final. Muito obrigado!

Durante nossas pesquisas sobre os mercados eletrônicos em setembro passado, observamos um aumento vertiginoso dos preços. Somos um grupo de hobbistas com zero poder de barganha com os fabricantes de eletrônicos. Até mesmo a respeitada fundação Raspberry Pi foi forçada a aumentar seus preços.

Consequentemente, cada protótipo ficou cerca de 300-320 euros mais caro, incluindo 22% de IVA local, representando um aumento total de 1000 euros, incluindo as taxas do PayPal para os três protótipos. Precisamos aumentar a meta da campanha de 12500 para 13500 euros.

No momento, não podemos dizer se os preços voltarão a baixar e, além disso, quando a atual escassez de componentes eletrônicos acabará. Todos nós esperamos que a situação melhore quando a produção total do lote começar.

Por outro lado, ser forçado a esperar por componentes eletrônicos é bastante compatível com o ritmo lento de nossa campanha de arrecadação, portanto, continue doando!!

Placas de vídeo MXM

Para ter uma idéia da atual escassez de eletrônicos, veja nossa compra da AMD Radeon E9172 MXM GPU (aproximadamente 295 EUR com IVA) e uma AMD Radeon E9174 MXM GPU (aproximadamente 380 EUR com IVA) em maio de 2021. A data de entrega prevista é 27 de novembro de 2021!

No momento, o custo das três placas MXM necessárias para os protótipos não são cobertos pela campanha de doação, mas pedimos seu apoio financeiro para elas também.

Enquanto isso, tivemos a oportunidade de comprar uma placa ATI Radeon HD4650 1GB DRR3 MXM 3.0 e, graças à gentil doação de Stefano, um novo colaborador da Itália, temos agora duas placas AMD FirePro M4000 GDDR5 1GB MXM 3.0A.

A ACube Systems, nosso parceiro que cuida da construção dos protótipos, também comprou um adaptador PCI para MXM. O adaptador nos permitirá testar as placas MXM antes de termos o protótipo pronto, pois ele será usado em conjunto com a placa-mãe “Sam460ex” feita pela ACube Systems. Os testes serão realizados sob AmigaOS 4.1, um sistema operacional PowerPC nativo.

Considerando atualizar para a licença Cern 2.0

Estamos estudando a possibilidade de atualizar nossa licença de Open Hardware de Cern 1.2 para 2.0.

A primeira coisa que notamos foi que a segunda versão está dividida em três variantes chamadas Strongly Reciprocal (S), Weakly Reciprocal (W) e Permissive (P). Basicamente, todos os três documentos são estruturados da mesma maneira e, na verdade, algumas seções são idênticas. As principais diferenças estão nas seções 3 Copiar, Modificar e Transmitir Fonte Coberta, 4 Fabricar e Transportar Produtos e 5 Pesquisa e Desenvolvimento (que não existe na licença Permissiva). As mudanças que podem ser encontradas comparando um documento com outro também implicam em conceitos diferentes a serem explicados na seção 1 Definições. A maioria dos termos que aparecem em mais de um documento tem a mesma definição. Exceções importantes a isto são 1.1 “Licença” que se refere à variante exata da licença em cada documento e 1.7 “Componente disponível” que não é exatamente o mesmo em R e W (e não existe em S).

Como entendemos, a variante deve ser escolhida dependendo das restrições relacionadas aos componentes (Componentes Disponíveis) e peças adicionais que poderiam ser adicionadas pelo Licenciado (Materiais Externos). A OHL-S especifica que toda “a Fonte Completa é a Fonte Coberta” e qualquer modificação deve ser distribuída usando a mesma licença. Por outro lado, a OHL-W permite a inclusão de Materiais Externos, o que significa que você pode adicionar algumas componentes ao projeto usando uma licença diferente. Finalmente, a licença Permissiva não menciona nada sobre Componentes Disponíveis e Materiais Externos, mas permite fazer ou publicar um Produto apenas incluindo todos os Avisos do Licenciador.

Para entender melhor as diferenças, os exemplos fornecidos na página FAQ do repositório Open Hardware são bastante explicativos:

O que são todos estes sufixos?

No domínio de software, existem três regimes de licenciamento geralmente reconhecidos para software livre e de código aberto: permissivo, copyleft fraco e copyleft forte. Há preferências e casos para cada opção, e o mesmo acontece com o hardware. Usamos a palavra “recíproco” ao invés de “copyleft” porque os direitos subjacentes em nosso caso não estão restritos aos direitos autorais. Portanto, quando você usa a licença, você precisa adicionar um Aviso aos seus projetos com um dos três sufixos a seguir: S, W ou P:

• O CERN-OHL-S é uma licença fortemente recíproca. Por exemplo, se você libera arquivos HDL sob o CERN-OHL-S e depois alguém usa esses arquivos em sua FPGA, quando distribui o bitstream (seja colocando-o online ou enviando um produto com ele) precisa disponibilizar o resto do design HDL também sob o CERN-OHL-S.
• O CERN-OHL-W é uma licença fracamente recíproca. Considerando-se o exemplo acima, se você liberar sua parte do projeto sob o CERN-OHL-W, alguém que distribui um bitstream que inclui sua parte não precisa distribuir o resto dos arquivos do projeto também.
• O CERN-OHL-P é uma licença permissiva. Permite às pessoas pegar seu código, relicenciá-lo e utilizá-lo sem qualquer obrigação de distribuir as fontes quando enviam um produto.

Em comparação com esta segunda versão, OSHL v1.2 não inclui os termos “Componentes Disponíveis” e “Materiais Externos”, o que dificulta o estabelecimento de uma relação direta com qualquer uma destas variantes. Isto nos faz pensar que provavelmente é mais similar à OHL-S.

Considerando a seção de Isenção de Responsabilidade, que é a que protege o Licenciador das questões legais e adverte o Licenciado sobre sua responsabilidade, ambas as versões têm uma escrita muito semelhante. A versão 2 é ligeiramente mais detalhada especificando que “O Licenciador não terá, na máxima extensão permitida por lei, nenhuma responsabilidade por […]” enquanto a versão anterior não mencionava os limites criados por lei. De qualquer forma, pensamos que estes limites são alheios e o significado da seção de Isenção de Responsabilidade é equivalente.

Mais uma vez, para comparar OSHL v1.2 e OHL v2, podemos fazer uso de uma pergunta na seção FAQ:

Sou um usuário do CERN OHL versão 1.2. Quais são as principais mudanças introduzidas por esta nova versão?

A versão 2 do CERN OHL melhora a versão 1.2 em vários aspectos:

• A nova versão vem em três variantes: fortemente recíproca, fracamente recíproca e permissiva. As licenças recíprocas estipulam que as alterações de um projeto devem ser devolvidas à comunidade, para que todos possam se beneficiar delas. As licenças permissivas não impõem esta condição. Desta forma, o CERN OHL v2 atende aos diferentes modelos de colaboração atualmente utilizados em projetos de Hardware de código aberto.
• Nas variantes recíprocas, é muito importante esclarecer o escopo das obrigações recíprocas. Ao introduzir os conceitos de “Componente Disponível” e “Material Externo”, mais o conceito já existente de “Produto”, a nova versão faz um esforço especial para esclarecer quais fontes devem ser compartilhadas tanto nas variantes -S como -W.
• A versão 1.2 do CERN OHL incluiu uma licença de patente, ou seja, uma promessa do licenciante de que não processará um licenciado por violação de patente no que diz respeito ao projeto licenciado sob o CERN OHL. A versão 2 acrescenta uma cláusula recíproca para esta licença de patente: se um licenciado processar um licenciante por violação de patente, ele(a) perderá todos os direitos concedidos pela licença.
• Na licença 1.2, não fizemos um esforço especial para atender ao desenvolvimento da Linguagem de Descrição de Hardware (HDL) como usada no Field Programmable Gate Array (FPGA) e no projeto de Circuito Integrado de Aplicação Específica (ASIC). Como ficamos convencidos de que não havia um regime de licenciamento recíproco apropriado para HDL, nos certificamos de que o CERN-OHL-S e o CERN-OHL-W podem fornecer uma boa solução para os projetistas de FPGA e ASIC com uma mentalidade recíproca.
• A versão 2 faz um esforço especial para maximizar as chances de que o destinatário de um produto físico tenha acesso aos arquivos de projeto para esse produto. Isto é feito concedendo ao licenciante a possibilidade de incorporar uma URL ou outra referência no próprio objeto, e estabelecendo que os licenciados downstream devem respeitar esse aviso e atualizá-lo conforme aplicável se o projeto for alterado. Se eles entrarem em conformidade dentro de 30 dias após receberem uma notificação do licenciador, seus direitos são restabelecidos. Isto se destina a ajudar nos casos em que um licenciado infrinja os termos da licença inadvertidamente.

Estamos ainda estudando qual alternativa é melhor da OHL-S, OHL-W e OHL-P. A decisão deve levar em conta quão livres queremos que os licenciados sejam quando produzimos ou modificamos nosso projeto.

Participe de nossas palestras no OpenPower Summit 2021, Linux Day Online Italy 2021 e na Sfscon 2021

Para notícias sobre nosso projeto e planos futuros, participe de nossas conversas durante:

Linux Day 2021 Online (23 de outubro de 2021 3 PM CEST): “Quando a comunidade produz um laptop de Hardware Aberto“, em italiano.

Na cimeira OpenPOWER NA 2021 (28 de outubro de 2021 às 2h45, horário de verão central (CDT), UTC -5): “Prepare-se para mudar a computação para a Arquitetura de Potência em Hardware Aberto“.

Na Sfscon.it: PPC64: Protótipos de Notebooks de Hardware Aberto estão chegando (12 de novembro de 2021 14h30 CEST).

Corra! Vote no nome da nossa placa-mãe!

A partir de 22 de outubro de 2021, alcançamos 987 dos 1000 votos necessários para tomar uma decisão final sobre o nome da placa-mãe. Gostaríamos de fechar as piscinas assim que tivéssemos atingido esse número para começar a trabalhar na redação de logotipos e outros materiais de comunicação.

Incorporando suporte ao PPC64 Big Endian ao Freedesktop-sdk

Graças a Charles e Manuel, membros de nossa equipe de software, enviamos um pedido de incorporação ao Freedesktp-sdk de um patch para permitir a compilação no PPC64 Big Endian. Essa foi uma grande conquista e um enorme esforço de nossos voluntários. Um ótimo trabalho, pessoal! Muito obrigado!!

O Freedesktop-sdk estava prestes a cessar o suporte à arquitetura PowerPC por não ter um builder . A situação agora mudou, e estamos agora muito felizes em informar que mesmo graças à ajuda dos membros do OpenPower (da OSUOSL), em termos de atualizações e melhorias na branch ppc64le do freedesktop-sdk.