Nível de Hackabilidade do raspberry pi

35

Trabalho com sistemas embarcados (principalmente microcontroladores) há cerca de 3 anos. Eu quero saber quanto de RPi de código aberto realmente? Eu sei que o arduino nos fornece detalhes completos de hardware / software, etc. Mas e o RPi? Isso é importante, pois minha equipe e eu quero fazer o seguinte com o raspberry pi [este projeto pretende usar o RPi exatamente como um arduino => no OS]:

  1. Reescreva o ROM (bootloader primário) para inicializar a partir do flash, e não do cartão SD externo.
  2. Tenha um carregador de inicialização secundário no flash integrado, isso ativa a porta usb do pi e a ouve. Ele deve aceitar o código binário (que será obtido no meu PC) e salvá-lo no flash. depois comece a executá-lo.
  3. Desenvolva nossos próprios drivers de dispositivo para lidar com protocolos de comunicação.
  4. Desenvolva nosso próprio ambiente de upload e depuração para o PI, juntamente com nossa implementação personalizada do C for ARM incorporado (necessário para controlar os GPIOs etc.).
  5. Implemente nosso próprio sistema operacional para sistemas embarcados, se possível.

Isso é possível com o raspberry Pi? Caso contrário:
-> Quais dos meus cinco objetivos não são possíveis com o raspberry pi. que mudanças devo fazer no meu projeto se tiver que trabalhar com o PI?
-> Que outras placas existem no mercado que me permitirão realizar exatamente o que quero?

deepak
fonte

Respostas:

76

Alguma experiência

A coisa mais importante que você deve saber é que o RaspberryPi é um animal estranho, onde ARM CPUnão é a CPU principal - é apenas um co-processador para o VideoCore GPU. Quando o RaspberryPi é iniciado, um blob de GPU é lido do cartão SD para o cache L2 e executado. Este código traz todos os periféricos importantes (RAM, relógios, etc) e inicia o ARM CPU. Em seguida, o gerenciador de inicialização do segundo estágio ou algum sistema operacional pode ser executado ARM CPU.

O blob da GPU não é apenas um gerenciador de inicialização. Na verdade, é um sistema operacional (Video Core OS) por si só. Alguns elementos importantes do sistema não são acessíveis diretamente pela CPU do ARM e eles precisam se comunicar GPU(usando mailboxo sistema de mensagens) para usá-los. Existe documentação parcial sobre isso disponível. O Now Video Core OS( VCOS) é estendido de tempos em tempos pelos funcionários da Broadcom para habilitar os recursos necessários ao Linuxkernel RISC OSou , às vezes, até alguns SOs de hobby. No entanto, não há uma boa documentação sobre isso, você teria que pesquisar RaspberryPi forum,githube possivelmente outros lugares para encontrar informações sobre isso. Mas está lá ... em algum lugar. E há algumas pessoas que escrevem seu próprio código bare metal ou até mesmo sistemas operacionais no RaspberryPi para ajudá-lo. E, claro, muito código-fonte aberto - o kernel Linux do RasbperryPi, por exemplo.

O VideoCore é proprietário, não há documentação oficial e ferramentas de desenvolvimento. Portanto, a menos que você queira fazer muito esforço, não poderá reescrever VCOScom seu próprio código. Há, no entanto, algum esforço para fazer a engenharia reversa do Video Core, você pode encontrar algumas informações aqui .

Outro problema é que a USBpilha da Synopsys é proprietária e, novamente, não há documentação para ela e parece que mesmo com a documentação é difícil implementá-la com segurança. Mas, novamente, o código está disponível (kernel do Linux, u-boot, CSUD ). O uso de recursos avançados de gráficos Video Coretambém pode ser difícil - há algum código-fonte aberto para as bibliotecas de gráficos, mas é apenas para o ARMlado.

Dito isso, foi possível disponibilizar a RISC OSporta a partir das informações (não está totalmente claro para mim se eles estavam usando apenas informações acessíveis ao público), algumas pessoas estão reescrevendo (independentemente da Broadcom) o kernel do Linux para a linha principal. é uma FreeBSDporta, 'U-boot` e outras. Portanto, é definitivamente possível escrever seu próprio sistema operacional. Não é tão fácil quanto poderia ser.

Seus objetivos

Número 1

Até onde eu sei, não há como o SoC começar de outra maneira que a descrita. Portanto, o carregador de inicialização do primeiro estágio deve estar ativado SD card. E tem que ser um GPUbinário, não um ARMbinário, que é outro problema. E não há flash integrado no RaspberryPi, o que também é um problema.

Número 2

O principal problema é que não há placa flashno RaspberryPi. Você pode adicionar um e ele pode ser ativado no seu carregador de inicialização (que já teria que ser o carregador de inicialização do segundo estágio). Escrever um driver USB pode ser problemático, no entanto.

Número 3, 4, 5

Isso não deve ser um grande problema. A maioria dos periféricos (pelo menos aqueles acessíveis ao ARM) está documentada aqui . O gerenciador de inicialização existente torna isso ainda mais fácil, pois você configura seu SoC completamente. Você pode procurar aqui e aqui algum código e documentação.

Alternativas

Eu não conheço nenhum outro conselho tão bom quanto o RaspberryPi, por isso é difícil recomendar algo, mas você pode dar uma olhada em alguns projetos maduros, como o Beagleboard / Beaglebone / Pandaboard, baseado em OMAP, ou acompanhar o desenvolvimento de alguns novos, como o Allwinner. Cubieboard ou PCduino . Tudo depende do que exatamente você deseja realizar.

Krzysztof Adamski
fonte
3
Quero +100 esta resposta. Bem feito.
Orithena 21/04
@maligree lol, não se preocupe - isso já foi feito! :)
xxmbabanexx 23/04
11
+1 para Beablebone porque é 100% opensource e você tem a capacidade de "respin" o hardware e fazer sua própria placa de circuito
portforwardpodcast
5

Para atualizar a excelente resposta de Krzysztof, a Broadcom finalmente lançou publicamente algum código, licenciado como 3-Clause BSD, para ajudar na criação de um driver de GPU de código aberto. O esforço "rpi-open-firmware" para substituir o blob de firmware do Raspberry Pi VPU começou em 2016: https://github.com/christinaa/rpi-open-firmware . Veja mais em https://news.ycombinator.com/item?id=11703842

Existem várias placas alternativas brevemente descritas e vinculadas a partir do RaspberryPi - Debian Wiki , incluindo ODROID-C1, Cubieboard, Banana Pi, OLinuxIno Wifi da Olimex e OlinuxIno Wifi e OlinuxIno Mini, EOMA68 e Beaglebone black.

nealmcb
fonte
Pessoalmente, acho que as alternativas não são tão boas, muitas placas ODROID reforçam a verificação de assinaturas no gerenciador de inicialização e impedem que você execute seu próprio código nelas. A família TI OMAP3 existe no modo seguro antes de chamar seu código, limitando também o que você pode fazer com ele. O VPU no RPi é realmente muito bom, acho que é o que dá vantagem a outras placas e agora que temos uma cadeia de ferramentas agradável para isso, as coisas parecem boas.
Kristina Brooks
1

Na verdade, você pode fazer muito com o gerenciador de inicialização U-boot com Raspberry Pi. Você basicamente deixa a GPU carregar seu SoC do coprocessador ARM com a imagem de inicialização U como o "SO".

Eu achei este artigo útil como exemplo. Ainda não o fiz, mas pretendo fazê-lo. Por acaso, encontrei sua pergunta enquanto procurava uma maneira de fazer isso sozinho. Depois encontrei o artigo e parecia que poderia ser útil para outras pessoas que procuravam algo semelhante.

outro artigo que contém instruções mais abrangentes para criar a imagem de inicialização U.

Alan Mimms
fonte
11
Esse é o tipo de resposta que pode ser útil no começo, mas depois de alguns anos os links param de funcionar e não há uma única dica sobre qual era o conteúdo deles. Considere pelo menos dizer qual ramificação de inicialização em U e qual compilador você usou.
Dmitry Grigoryev
Obrigado Dmitry. Voltarei a isso em breve e corrigirei quando tiver algum tempo.
Alan Mimms