Nivel de Hackability de frambuesa pi

He estado trabajando con sistemas integrados (en su mayoría microcontroladores) durante aproximadamente 3 años. ¿Quiero saber cuánto RPi de código abierto realmente? Sé que Arduino nos da detalles completos de hardware / software, etc. ¿Pero qué pasa con RPi? Esto es importante ya que mi equipo y yo queremos hacer lo siguiente con la frambuesa pi [este proyecto pretende usar el RPi exactamente como un arduino => no OS]:

1. Vuelva a escribir el gestor de arranque primario (ROM) para arrancar desde flash en lugar de desde una tarjeta SD externa.
2. Tener un cargador de arranque secundario en el flash incorporado, esto activa el puerto usb del pi y lo escucha. Debe aceptar el código binario (que obtendrá de mi PC) y guardarlo en la memoria flash. luego comienza a ejecutarlo.
3. Desarrolle nuestros propios controladores de dispositivo para manejar protocolos de comunicación.
4. Desarrollemos nuestro propio entorno de carga y depuración para el PI, junto con nuestra implementación personalizada de C incrustado para ARM (necesario para controlar GPIO, etc.).
5. Implemente nuestro propio sistema operativo para sistemas integrados si es posible.

¿Es esto posible con la frambuesa Pi? Si no:
-> ¿Cuál de mis cinco objetivos no es posible con la frambuesa pi? ¿Qué cambios debo hacer en mi proyecto si tengo que trabajar con el IP?
-> ¿Qué otras tablas hay en el mercado que me permitirán lograr exactamente lo que quiero?

Algunos antecedentes

Lo más importante que debe saber es que el RaspberryPi es una bestia extraña donde ARM CPUno es la CPU principal, es solo un coprocesador para el VideoCore GPU. Cuando se inicia RaspberryPi, se lee un blob de GPU de la tarjeta SD en el caché L2 y se ejecuta. Este código muestra todos los periféricos importantes (RAM, relojes, etc.) e inicia el ARM CPU. Luego, se puede ejecutar el cargador de arranque de la segunda etapa o algún sistema operativo ARM CPU.

GPU blob no es solo un gestor de arranque. En realidad, es un sistema operativo (Video Core OS) en sí mismo. ARM CPU no puede acceder directamente a algunos elementos importantes del sistema y tiene que comunicarse con ellos GPU(mediante el mailboxsistema de mensajería) para usarlos. Hay documentación parcial sobre esto disponible. Now Video Core OS( VCOS) se extiende de vez en cuando por los empleados de Broadcom para habilitar las funciones que necesita el Linuxkernel, RISC OSo , a veces, incluso algunos sistemas operativos hobby. No hay buena documentación sobre esto, sin embargo, tendría que cavar en el RaspberryPi forum,githuby posiblemente otros lugares para encontrar información sobre esto. Pero está ahí ... en alguna parte. Y hay algunas personas que escriben su propio código de metal desnudo o incluso sistemas operativos en el RaspberryPi para ayudarlo. Y, por supuesto, una gran cantidad de código fuente abierto, el kernel de Linux de RasbperryPi, por ejemplo.

VideoCore es propietario, no hay documentación oficial ni herramientas de desarrollo. Entonces, a menos que quiera poner mucho esfuerzo, no puede volver VCOSa escribir con su propio código. Sin embargo, hay algún esfuerzo para aplicar ingeniería inversa al Video Core, puede encontrar información aquí .

Otro problema es que la USBpila de Synopsys es propietaria y nuevamente no hay documentación para ello y parece que incluso con la documentación es difícil implementarla de manera confiable. Pero nuevamente, el código está disponible (kernel de Linux, u-boot, CSUD ). El uso de capacidades gráficas avanzadas Video Coretambién puede ser difícil: hay un código fuente abierto para las bibliotecas de gráficos, pero es solo para el ARMlado.

Dicho esto, fue posible hacer que el RISC OSpuerto a partir de la información esté disponible (no me resulta del todo claro si solo usaban información de acceso público), algunas personas están reescribiendo (independientemente de Broadcom) el kernel de Linux para mainline, allí es un FreeBSDpuerto, 'U-boot' y otros. Por lo tanto, es definitivamente posible escribir su propio sistema operativo. Simplemente no es tan fácil como podría ser.

Tus metas

Numero 1

Hasta donde yo sé, no hay forma de que el SoC pueda comenzar de una manera diferente a la descrita. Así que el gestor de arranque de la primera etapa tiene que estar activado SD card. Y tiene que ser un GPUbinario, no un ARMbinario, que es otro problema. Y no hay flash incorporado en el RaspberryPi, que también es un problema.

Número 2

El principal problema es que no hay una placa integrada flashen RaspberryPi. Puede agregar uno y podría activarse en su gestor de arranque (que ya debería ser el gestor de arranque de la segunda etapa). Sin embargo, escribir un controlador USB podría ser problemático.

Número 3, 4, 5

Esto no debería ser un gran problema. La mayoría de los periféricos (al menos los accesibles para el ARM) están documentados aquí . El gestor de arranque existente lo hace aún más fácil ya que configura su SoC por completo. Puede buscar aquí y aquí algún código y documentación.

Alternativas

No conozco ninguna otra placa tan buena como RaspberryPi, por lo que es difícil recomendar algo, pero puedes echar un vistazo a algunos proyectos maduros como Beagleboard / Beaglebone / Pandaboard basados ​​en OMAP o puedes seguir el desarrollo de algunas nuevas tablas como Allwinner Cubieboard o PCduino . Todo depende de lo que quieras lograr exactamente.

Para actualizar la excelente respuesta de Krzysztof, Broadcom finalmente lanzó públicamente un código, licenciado como BSD de 3 cláusulas, para ayudar a crear un controlador de GPU de código abierto. El esfuerzo "rpi-open-firmware" para reemplazar el blob de firmware de VPU Raspberry Pi comenzó en 2016: https://github.com/christinaa/rpi-open-firmware . Ver más en https://news.ycombinator.com/item?id=11703842

Hay una serie de tableros alternativos brevemente descritos y vinculados desde RaspberryPi - Debian Wiki , incluidos ODROID-C1, Cubieboard, Banana Pi, OLinuxIno Wifi de Olimex y OlinuxIno Mini, EOMA68 y Beaglebone black.

En realidad, hay muchas cosas que puedes hacer con el gestor de arranque U-boot con Raspberry Pi. Básicamente, simplemente deja que la GPU cargue su SoC coprocesador ARM con la imagen de arranque en U como el "SO".

Encontré que este artículo fue útil como ejemplo. No lo he hecho (todavía), pero planeo hacerlo. Por casualidad encontré tu pregunta mientras buscaba una forma de hacerlo yo mismo, y luego encontré el artículo y parecía que podría ser útil para otros que buscan algo similar.

Hay otro artículo que contiene instrucciones más extensas para construir la imagen U-boot.