Graças aos nossos apoiadores, chegamos lá de novo!
A campanha de doação para financiar três protótipos atingiu seu objetivo no domingo 24 de outubro com uma surpreendente aceleração final graças à maior doação já recebida, que nos fez pular em nossas cadeiras quando a vimos. Obrigado a todos vocês e, especialmente, muito obrigado ao Wiktor Glowacki!
Transferimos o dinheiro arrecadado pela campanha à ACube Systems, a empresa que selecionamos para a jornada desafiadora para fazer um notebook PowerPC. No momento, estamos enfrentando alguns atrasos devido às dificuldades da cadeia de fornecimento da indústria eletrônica (veja nosso post sobre isso), e a ACube está no momento aguardando os últimos componentes eletrônicos para finalmente construir as três placas.
Agora estamos prontos para lançar a próxima campanha de arrecadação, para financiar os testes de hardware, com meta de 14.000 euros.
A nova campanha começa hoje, e as doações serão transferidas para a ACube. Nossa esperança é concluir esta nova campanha em menos de 10 meses, mas isso dependerá em grande parte de seu apoio.
Logo após testarmos os três protótipos, publicaremos uma versão atualizada dos diagramas eletrônicos em nosso repositório GitLab, para que o projeto disponível ao público seja uma versão meticulosamente revista.
Estamos relativamente confiantes de que as doações se acelerarão quando pudermos mostrar publicamente os protótipos físicos, pois isso deverá melhorar a credibilidade do nosso projeto.
Lembramos que depois desta nova campanha para realizar os testes de hardware necessários, a próxima campanha é para a certificação de hardware CE com uma meta de 12500 euros, e então finalmente estaremos prontos para a produção em massa!
Um grupo de gurus para configurar o U-Boot
A nova campanha de arrecadação financiará o trabalho realizado pela ACube Systems e seu projetista de hardware para os testes de hardware.
Esforçaremo-nos bastante para contribuir com o processo de desenvolvimento, trabalhando no boot-loader U-Boot. Esta tarefa é bastante urgente, e estamos atualmente criando um grupo central de voluntários com alguns conhecimentos de U-Boot e árvores de dispositivos necessários para inicializar o hardware.
Como anunciado em um post publicado em 2018, tivemos alguma experiência na configuração do U-Boot quando montamos nosso kit de desenvolvimento, o NXP T2080-RDB. Nossa configuração foi baseada na versão antiga U-Boot originalmente fornecida com o kit (QorIQ SDK v2.0-1703).
Um exemplo dos problemas que estamos enfrentando é que o nosso build atual do U-Boot não inicializa a placa de vídeo, portanto, a única maneira de interagir com o U-Boot é através de um terminal serial remoto. Este problema precisa ser resolvido para melhorar a usabilidade geral da placa-mãe.
Você pode dar uma olhada nos passos que seguimos enquanto trabalhamos com o U-Boot em nosso wiki, e na documentação abrangente e detalhada no site da nossa associação.
Abaixo você pode encontrar um commit feito em 2018 ao U-Boot original, compilado em 2017, que foi fornecido com o NXP SDK v2.0-1703.
O plano é começar a trabalhar na última versão do U-Boot (2021-10), estamos em dúvida se devemos começar pelo repositório oficial da linha principal do U-Boot ou, alternativamente, pelo repositório U-Boot QorIQ. Qualquer conselho sobre qual é a melhor escolha é geralmente bem-vindo (por favor, acrescente um comentário a este post).
Abaixo, você pode encontrar um link para o que trabalhamos em 2018 a fim de iniciar o Linux no NXP Development Kit T2080-RDB:
https://gitlab.com/power-progress-community/oshw-powerpc-notebook/T2080customizations
Um grupo de gurus para compilar o kernel
Qualquer pessoa disposta a ajudar nesta área deverá testar qualquer novo lançamento do kernel Linux para identificar quaisquer mudanças que possam impedir o uso de uma plataforma baseada em CPU NXP T2080, como a placa-mãe do nosso notebook.
Infelizmente, estas tarefas exigem o uso direto de um hardware que monta a mesma CPU usada na placa-mãe do notebook e não podemos dar acesso ao nosso NXP T2080RDB a ninguém. Enquanto esperamos que os protótipos fiquem prontos, pouco podemos fazer nesta área. Mas, mesmo assim, se você estiver interessado em ajudar, pode começar a investigar as diferenças entre as famílias Book3e e Book3s PowerPC, tendo em mente que o T2080 pertence à família Book3e, e especificamente à variante NXP e6500. A principal lista de discussão dos desenvolvedores do kernel Linux é https://lists.ozlabs.org/pipermail/linuxppc-dev/.
Até o presente momento, testamos e usamos com sucesso kernels até 5.12.x no nosso DevKit NXP T2080RDB, mas não conseguimos executar kernels a partir da versão 5.13.x. O kernel simplesmente se recusa a carregar. A causa está atualmente sob investigação.
Se você estiver disposto a nos ajudar, por favor, entre em contato conosco e tentaremos conceder acesso ao T2080RDB.
Esta é a página do GitLab onde mantemos registro dos núcleos testados no DevKit.
Precisamos consertar o KVM nos núcleos e6500
CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=24109871
Uma outra área, mas estreitamente ligada ao kernel, é o suporte à KVM (máquina Virtual baseada no Kernel) que atualmente não funciona em nossos testes com o T2080RDB. Este é um recurso essencial, pois permite ao usuário gerenciar máquinas virtuais rodando em velocidade quase nativa, pois não precisam emular a CPU (o KVM é capaz de usar diretamente a CPU do computador host).
Estamos bastante confiantes de que com um esforço relativamente pequeno poderia funcionar porque há pessoas usando KVM em uma CPU muito semelhante, a NXP P5020, que é uma CPU Book3e, especificamente a variante e5500, a CPU NXP da geração anterior. Você pode dar uma olhada abaixo nos resultados alcançados por Christian Zigotzky em seu AmigaOne X5000, um computador atualmente sendo vendido pela A-Eon e baseado no NXP
Listas discutindo QEMU e KVM no PowerPC:
Um grupo de gurus em problemas de endianness
Outra importante tarefa que planejamos realizar enquanto os protótipos estão sendo preparados é coordenar um grupo capaz de identificar e corrigir problemas que impedem que distribuições Linux para PPC64 (Big Endian ou simplesmente BE) como Debian, VOID ou MintPPC trabalhem na placa-mãe. Outras distribuições Linux como Ubuntu (última versão suportada 14.04) ou Fedora (última versão suportada 28) abandonaram o PPC64 há muito tempo, seria ótimo vê-las novamente suportadas, mas isso é muito ambicioso no momento.
O plano é identificar quais software têm problemas na nossa CPU NXP T2080, muito provavelmente devido a problemas de endianness, identificar o conjunto de mudanças necessárias no código fonte e, em seguida, enviar um patch aos mantenedores do software. O problema que estamos enfrentando é que a grande maioria dos softwares modernos é projetada para funcionar apenas em CPUs Little Endian e, na maioria das vezes, os desenvolvedores não testam seus softwares em nenhuma plataforma Big Endian, também porque elas estão se tornando cada vez mais raras.
Como ter acesso a um T2080RDB pode ser um problema, podemos dizer que em nossa experiência a CPU NXP T2080 se comporta de forma bastante semelhante à CPU G5 (PowerPC 970), a última CPU de 64 bits disponível comercialmente com Altivec, utilizada pela Apple em sua linha de Macs baseados em PowerPC. Se um software funciona bem no G5, há uma grande chance de que ele funcione bem no T2080 também. Claro, o T2080 gasta muito menos energia que G5, mas o G5 seria o companheiro perfeito para realizar a investigação enquanto nossa placa-mãe de notebooks fica pronta. Outra diferença com relação à CPU G5 a se ter em mente é que a T2080 pertence à família de CPU Book3e onde o “e” significa “embedded”, enquanto que a G5 é uma CPU Book3s (aka sPAPR), veja nesta página uma explicação esquemática das famílias PowerPC (https://www.kernel.org/doc/Documentation/powerpc/cpu_families.txt). Uma explicação mais detalhada das características da família de CPU Book3e está disponível aqui: https://www.nxp.com/docs/en/user-guide/BOOK_EUM.pdf.
Sugerimos a qualquer pessoa interessada em ajudar no trabalho usar um Power Mac G5 com uma placa Radeon HD, e instalar a versão big endian PPC64 do Debian (https://cdimage.debian.org/cdimage/ports/current/).
Também estamos procurando qualquer pessoa com algum conhecimento sobre como ajustar o software para permitir o suporte Altivec, um ponto flutuante de precisão única e um conjunto de instruções SIMD inteiro que melhoraria muito a experiência do usuário quando suportado.
Nos últimos anos, identificamos algumas áreas-chave de software potencialmente afetadas por questões de endianness que podem ter um forte impacto no uso diário da plataforma, mas três áreas são, em nossa opinião, as mais relevantes:
- Qualquer coisa relacionada ao uso de GPUs modernas da AMD Radeon. Selecionamos as GPUs AMD para nossa placa-mãe, já que, de modo geral, estas placas parecem se comportar bastante bem quando usadas em um ambiente big endian. O problema é que qualquer atualização em qualquer coisa relacionada ao uso destas placas de vídeo pode causar erros impedindo qualquer saída de vídeo, por exemplo, atualizações no kernel, no X11, Mesa para software 3D, e mais recentemente Wayland ou Vulkan. Por exemplo, uma atualização recente do SID do Debian para PPC64 quebrou algo e agora não podemos iniciar nenhuma sessão do X11 em nenhuma Radeon HD que tentamos. A causa está sob investigação.
- A aceleração de hardware de vídeo também deve ser investigada, então precisaríamos de alguém capaz de lidar com problemas relacionados às tecnologias específicas da AMD Radeon, tais como Unified Video Decoder (UVD), Video Code Engine (VCE) e Video Core Next (VCN). Os softwares que utilizam estas tecnologias e devem ser cuidadosamente investigados são VLC, mplayer e a parte de decodificação de vídeo dos navegadores da Web, a fim de permiti-los reproduzir vídeos em velocidade máxima porque a CPU não é suficientemente potente para decodificar transmissões de vídeo FullHD ou 4K.
- Navegadores da Web. Estes softwares são as aplicações mais utilizadas por qualquer tipo de usuário e sem eles o notebook não tem nenhuma chance de ser atraente para ninguém. O navegador mais estável e eficiente na experiência são o ArcticFox e o InterWebSnow.
