Hier, tout fébrile, j’ai reçu mon tout nouveau Raspberry Pi 2. Il est très proche d’un B+, si ce n’est qu’il y a une puce en plus en dessous du circuit. Comme la puce principale est estampillée Broadcom (alors que sur les précédents modèles elle porte la marque de la mémoire, qui était greffée dessus), j’en ai déduis que cette nouvelle puce côté pile devait être la mémoire (de 1 Go). C’est la seule différence entre le Raspberry Pi 2 et le Raspberry Pi B+ (à quelques composants près j’imagine). Tout reste compatible. Les boîtiers, les extensions, les logiciels (le ARM v7 du Raspberry Pi 2 est rétro-compatible avec le ARM v6 du Raspberry Pi 1).

Comme pour mon précédent Raspberry Pi B+, j’ai opté pour l’Ultimate Starter Kit de chez Vilros (voir ci-contre), sur Amazon. J’étais certain d’avoir tous les accessoires nécessaires (dissipateurs, boîtier, alimentation, câble HDMI, dongle WiFi qui vaut le détour), et d’enrichir mon kit de prototypage d’une breadboard et de jumpers supplémentaires, et d’une break-out board (un repport de connecteur GPIO) absolument idéal. La seule chose que je n’ai pas trop apprécié par rapport au B+, c’est que Vilros a sérigraphié le boîtier de leur logo. J’estime que ce genre de chose devrait être réservé aux produits promotionnels, et pas aux produits commerciaux. Mais mis à part ce petit détail, je continue à estimer que ce kit vaut son prix.

Mise en service

Je le branche, je l’alimente, et … Rien. L’écran de test du GPU me montre fièrement son plus beau dégradé, mais ne passe visiblement pas la main au CPU. Seule la LED d’alimentation est allumée. Le souci existait déjà à la sortie du Raspberry Pi B+. L’ancien bootloader ne gère pas cette nouvelle mouture. Qu’à cela ne tienne, je remets la carte SD dans le B+, et je le met à jour :

Et je vois bien défiler dans les mises à jour le fameux bootloader. Je redémarre, une fois sur le B+ pour la forme, et finir de tout bien installer, puis une seconde fois sur le Raspberry Pi 2. Cette fois il boot.

Première impression, ça va plus vite. Est-ce psychologique ou réel, je n’en sais rien (who cares ?). La framboise qui apparaissait lors du boot est accompagnée de 3 frangines, certainement pour symboliser le nombre de coeurs du Raspberry Pi 2.

Sous XBMC, la lecture est fluide, ne consomme pas de CPU.  »htop », pendant une lecture, a du mal a montrer plus d’un pourcent de charge sur l’un ou l’autre des cœurs. Niveau température, on tourne aux alentours de 52 °C, sans overclocking, sans dissipateur.

En revanche, gros souci, mais très certainement inhérent à XBMC puisque déjà vu sur d’autres plateformes : La navigation est d’une lenteur incroyable ! Sur Raspberry Pi B ou B+, elle est fluide. Sur Raspberry Pi 2, sur Nexus 5 et sur Galaxy Tab 4, elle est inutilisable. D’après htop, ce n’est pas un problème de CPU. Il reste à zéro. La mémoire non plus. Mais quand on entre dans un dossier, XBMC vous regarde droit dans les yeux, s’assied, et s’allume une clope. 10 bonnes secondes après un « clic » (de télécommande), le loader apparaît enfin, et le navigateur entre dans le dossier. Si vous allez chercher une vidéo à 10 niveaux de profondeur, il vous faudra pas moins d’une minute pour aller la chercher.

Edit du 08/02/2015: Pour infos, l’installation de Retropie à partir des sources prend 10h. Et ne fonctionne pas 🙁

Edit du 02/06/2015: La lenteur de navigation sous XBMC était due au systèmes de fichiers utilisés. J’avais testé en HTTP et en SSH sans succès. Jamais je n’aurai pensé à mettre en place un partage CIFS (Windaube). Jusqu’au jour où j’ai été forcé de le faire, pour une raison totalement indépendante. Et là miracle, la navigation est totalement fluide sur ce type de partage. Une stupidité de plus à mettre sur le compte du nombre d’utilisateur de ce … système (oui, j’ai du mal à l’appeler comme ça), qui oriente fatalement les développement d’XBMC. Cela vaut aussi bien pour XBMC Linux que pour XBMC Android.