Logic-Sunrise : actualités, téléchargements, releases, dossiers et tutoriaux

Un wiki accessible en lecture/écriture est également disponible, n'hésitez pas à le corriger, l'agrémenter, et intervenir dessus, un travail de traduction vers l'anglais serait également fort utile => https://wiki.osremix...ation_4/manjaro
 
De même, afin de fédérer un maximum de monde, n'hésitez pas à traduire les news pour sur des sites étrangers de la scène PS4, l'issue de la scène PS4 dépend aussi des efforts que chacun d'entre vous est prêt à fournir pour supporter celle ci.

Edit : d'après les retours, l'accélération matérielle du driver GPU sur les anciennes PS4 fonctionnerait bien, le problème s'apparenterait en fait à un problème de la gestion de la fréquence du GPU, Gnome réclame quelques ressources GPU mais pas suffisamment pour faire monter rapidement le GPU en fréquence, de fait donc, les performances GPU se révèlent alors insuffisantes pour faire tourner l'environnement de façon fluide.
Quelques personnes ont pu s'apercevoir de ça car en lançant n'importe quelle application 3D l'environnement de bureau retrouvait une fluidité quasi normale (excepté les ressources utilisées par ladite application.)
En tapant la commande "dmesg" vous devriez voir les erreurs de gestion de la fréquence d'horloge du gpu, en question, sur ce point, le driver n'est pas encore au top.
MATE, LXDE, XFCE (XFCE était l'environnement de bureau proposé sous Fedora avec ces drivers GPU de la team Fai0verflow) sont des environnements moins beau esthétiquement, mais avec l'avantage de ne pas réclamer de ressources GPU (composites) de base, ça explique que ces derniers demeurent fluides, et que lorsque l'on lanc des apps 3D dessus elles tournent, car ces dernières réclament suffisamment de ressources GPU pour pousser le pilote GPU à monter en fréquence max ce dernier.
Pour ceux qui auraient des soucis avec leur modèle de PS4 donc (le problème n'existe sans doute pas sur ps4 Pro parce que les fréquences minimales du GPU doivent être plus élevées, et ce dernier donc plus performant), utilisez MATE ou installez un autre environnement de bureau, pour l'instant.

 
Bonjour, il semblerait qu'au vu de certains retours, il y ait nécessité de faire le point concernant les avancements de la scène Linux sur PS4.
 
Actuellement, la dernière release «accessible» que j'ai proposé est Manjaro Linux PS4 V2.
 
Dans les faits, ce n'est rien de moins que la version PC préinstallée, pré-configurée et rendue disponible via une image disque, personnalisée par mes soins, ou ont été installés les paquets fournis par la team PS3ita, et dont le le noyau Linux patché et compilé par EEPLY à été mis à jour apportant cette fois l'unification du bridge DP<=>HDMI plutôt qu'uniquement le support des dernières PS4 (incluant les pro) avec bridge Panasonic MN864729.

Visiblement, le patch des pilotes du GPU, des serveurs d'affichages Xorg et Wayland, ainsi que MESA (implémentation d'OpenGL libre) empaqueté et compilé par la team PS3ita semble fonctionner sur PS4 Pro, mais casse le support du GPU des autres PS4 [correction, voir la mise à jour de l'article] d'après les premiers retours des utilisateurs. (Et moi même, je n'ai qu'une PS4 Pro)

De fait, je conseille ainsi à tous ceux qui n'ont pas de PS4 Pro (ou veulent encore plus de fluidité au détriment de l'esthétique) de commencer par ne pas utiliser Gnome en l'état sur la V2, qui est plus gourmand en ressources que Mate, et d'utiliser ce dernier lui aussi, préinstallé.
 

 
Pour ceux qui voudraient tenter l'expérience, je conseille donc, lorsque vous êtes sur l'écran de connexion, de cliquer sur la petite roue crantée et choisir Mate (ou LXDE, si vous les installé, pour avoir testé, c'est bien plus rapide que Gnome 3, mais clairement moins chatoyant, c'est valable aussi pour les PS4 pro, un simple test avec la commande glxgears vous le confirmera au nombre de fps comptabilisés, en équivalence avec la vieille release de Fedora.)
 

Pour ceux qui seraient sur Manjaro V1, vous pouvez vous contenter de mettre à jour le noyau Linux proposé par le dernier fichier BZIMAGE d'EEPLY dans la partition FAT afin de profiter de l'affichage et de son dernier noyau.

Pour ceux qui voudraient malgré tout profiter de la V2 (qui n'apporte qu'un peaufinage esthétique, rétroarch préinstallé, un environnement de bureau Gnome complètement pré-configuré, en plus des drivers GPU de la team PS3ITA issus des patchs de la team Fai0verflow déjà intégré dans la vieille release de Fedora) vous pouvez tenter de désinstaller les pilotes et outils patchés puis réinstaller ceux d'origine via ces commandes.
 
(Si certains d'entre vous me confirment bien que la V1 fonctionne bien sur leur ps4 fat/slim, alors je proposerais un IMG de la V2 pour vous, prêt à l'emploi)
 
sudo rm /usr/lib/xorg/modules/extensions/libglx.so

yaourt -Rdd mesa-git lib32-mesa-git libdrm-git lib32-libdrm-git xorg-server-git wayland-git

yaourt -Rdd xf86-video-ati-git

yaourt -S mesa lib32-mesa libdrm lib32-libdrm xorg-server wayland

yaourt -S xf86-video-ati

 
Pour être bien clair, je n'ai pas choisi Gnome au hasard, certes, les performances sont moindre avec l'environnement en question dans le cas présent, mais je voulais proposer une bonne base, moderne, et attirante esthétiquement, l'environnement en soit n'est pas réellement si gourmand, sur PC même un GPU intel intégré est capable de le faire tourner proprement du moment que les pilotes GPU suivent.
 
Mais le support des pilotes GPU est encore très expérimental actuellement sur PS4 fat/slim/pro a un rendement tout juste utilisable, au mieux ce ne sont que des révisions ALPHA, tant qu'il en sera ainsi, la stabilité et la fluidité n'en sera pas garantie, mais ça n'empêche pas de pousser vers le haut et proposer ce qui se fait de mieux, je n'avais pas spécialement envie de proposer un bureau "lambda" un peu vieillot par défaut, Manjaro étant une distribution moderne basée sur ArchLinux, avec un environnement constamment mis à jour vers les dernières versions et derniers apports, une vitrine technologique de ce qui peut se faire de mieux sous GNU/Linux, en somme.
J'ai malgré tout laissé le choix, sur l'écran de connexion, où l'on peut choisir de lancer Gnome (qui est la version 3) ou MATE (qui est un fork de la version 2 de Gnome, plus vieillotte, mais moins gourmande en ressources, et donc, dans l'affichage 2D, moins de soucis de fluidité.)
De plus, vous remarquerez aisément en testant simplement que les performances d'affichage et de rendements 3D, dans toutes les situations, sont bien supérieures en 720P (1280x720) qu'en 1080p (1920x1080).
 
 

À toutes les personnes qui constatent les/des bugs, quels qu'ils soient, faites à minima après avoir constaté le problème, le nécessaire, en ouvrant des rapports de bugs sur les pages de projets concernés, c'est le seul moyen de faire avancer les choses, il faut que les gens comme vous et moi se bougent et participent pour faire avancer le tout, et remonter les infos aux développeurs, voir même si vous êtes développeur, contribuer ! (Ou même, parler des releases sur des sites dans des langues étrangères pour fédérer du monde autour de ces projets)
 
Eeply (noyau & sources Linux): https://github.com/eeply/ps4-linux/

Valentinbreiz (Payload loader noyau Linux): https://github.com/valentinbreiz/PS4-Linux-Loader/

Ps3itaTeam (Port des drivers GPU (paquets utilisés dans Manjaro PS4 v2), wifi, Bluetooth, etc...): https://github.com/Ps3itaTeam/ps4linux-video-drivers

Fail0verflow Team (Patch des pilotes 3D open source ATI/AMDGPU) https://github.com/fail0verflow/ps4-radeon-patches

xf86-video-ati (Pilotes 3D libres pour GPU AMD) => https://cgit.freedesktop.org/xorg/driver/xf86-video-ati/

xf86-video-amdgpu (Pilotes 3D libres pour GPU AMD) => https://cgit.freedesktop.org/xorg/driver/xf86-video-amdgpu/

Vultra (Payload loader Linux) : https://github.com/Vultra/PS4-4.55-Linux-Loader/

 
Sur le reste,  la team PS3ITA travaille toujours sur le support des drivers Wifi, Bluetooth, audio, et même Ethernet de certains modèles de PS4, toutefois, ils n'ont encore jamais délivré sur leur dépôt github, pas plus qu'un fichier BZIMAGE contenant un noyau compilé avec leurs patchs. D'après leur topic en italien, ils comptent proposer une distribution également prête à l'emploi (qui sera vraisemblablement ArchLinux, étant donné leur support et paquets proposés.)

Concernant le support de Vulkan sur PS4 (qui pourrait faire exploser les performances sur les émulateurs & jeux compatibles, sans se soucier des performances OpenGL des drivers GPU), nous n'avons actuellement aucune idée d'où cela peut il en être, les news les plus récentes faisaient état que le développeur MARCAN avait travaillé sur le support de ce dernier en début d'année dernière, mais depuis, plus de nouvelles, rien n'a été délivré, n'hésitez pas à l'interroger à ce sujet !
 
 
La scène PS4 est encore bien loin de l'âge d'or de la première Xbox en comparaison, et a besoin de toutes les bonnes volontés disponibles, et, c'est, en tout cas, le principe même qui régit le monde du libre et de tout ce qui entoure les projets liés à GNU/Linux.
Contrairement à beaucoup de développeurs de la scène console qui font souvent de la rétention, il s'agit ici de maximiser la coopération et les bonnes volontés, partager, expérimenter.
 
 
Questions/réponses utiles dans les commentaires :
 

Tikilou par quelle méthode lances tu le payload Linux ? Pas moyen chez moi avec esp ou tel android , j’ai testé plusieurs payload mais rien n’y fait
Merci d’aVance

PS4 exploit Host d'Al-Azif (https://github.com/A...t-host/releases) avec le payload de ValentinBreiz (https://github.com/v...oader/tree/4.55 [fichier PS4-Linux-Loader-4.55.bin])

Voilà que la Team LibRetro nous gratifie d'une nouvelle version de RetroArch qui débarque en v1.7.2, l'émulateur multi-plates formes apporte de nombreuses évolutions notamment une meilleur latence sur les consoles que vous émulez.           Une des fonctions importantes de RetroArch 1.7.2 est le "Runahead Latency Reduction", il s'agit là d'une fonctionnalité qui permet de réduire la latence, rendant votre expérience de jeux encore meilleure car la latence est encore plus faible via le blocage du décalage d'entrée.             Cette gestion de la latence est encore meilleure que sur les appareils réels et les performances d'affichage en sont grandies.             Tout se joue sur le nombre de frame qu'il va falloir adapter en fonction du jeu est de la plate-forme.    Ce n'est pas tout, RetroArch améliore le support de DirectX11 avec le support amélioré pour certains drivers, mais DirectX10 a aussi été amélioré de fait certains PC plus ancients profitent aussi de meilleurs rendus.         Tout est là : libretro.com   Téléchargement : retroarch-1-7-2    

Le développeur SGKleba propose une mise à jour de BootLogo Manager, l'application qui permet de supprimer ou de remplacer le logo de la Team Molecule d'Enso par celui de Sony.           Le programme est désormais disponible en Bêta 5, elle introduit de nouvelles options qui sont accessibles depuis le menu principal en appuyant sur triangle, ainsi il est possible de réparer le logo, de flasher un logo personnalisé ou encore changer la couleur de l'interface.         Si vous le souhaitez vous avez aussi la possibilité de changer le logo du mode recovery mais attention car là vous touchez aux fichiers systèmes.           Molecule's Boot Logo manager v5 Changelog :   - Ajout des "options avancées" (appuyez sur triangle dans le menu principal) - Vous pouvez maintenant désactiver l'affichage de bootlogo - Vous pouvez maintenant flasher un logo "cassé" - Ajout de l'option de flash d'un logo personnalisé d'enso - Vous pouvez maintenant changer la couleur de l'interface utilisateur           Téléchargement : BootLogo Manager Beta 5  

 

A la vue des derniers leaks et découvertes en matière de hacks Nintendo Switch, le développeur Plutoo a décidé de ne plus travailler pour la scène Switch, il a diffusé le code de l'exploit utilisé sur le firmware 3.0.0, chronique d'un mal.       Tout commence lorsqu'un anonyme a publié le code BootRom du Tegra X1, concrètement cela signifie que tout le monde a accès désormais à des avancées qui débloquent la scène, mais cela prive de l'intérêt de développer en privé.   Les scènes fonctionnent sur un système privé, public, il faut l'entendre, les développeurs travaillent gratuitement et leur seul plaisir est de pouvoir justement contrôler la propagation des avancées, quand on leur prive de ce plaisir, leur travail n'a plus d'intérêt, c'est ce que pense une majorité de développeurs de l'ombre, et Plutoo donc s'est probablement senti blessé par ce leak (ou cela a débouché sur son retrait "officiel" car dans les faits il avait déjà pris du recul depuis quelques semaines).   Il a dans un premier temps diffusé un tweet dans lequel il crie son désespoir invectivant le leakeur, puis un autre dans lequel il annonce son retrait de la scène et mettant en lumière l'intégralité de l'exploit utilisé qui a débouché sur le loader nx-hbmenu.   De nombreux acteurs de la scène sont surpris, et l'invitent à le rejoindre sur des scènes plus matures, d'un autre côté ce sont souvent les leaks qui font avancer publiquement les choses, regardez la scène PlayStation 4, et là on annonce l'arrivée du CFW pour Switch dans quelques semaines.     Le code source : Twitter de Plutoo     L'annonce du retrait de la scène : Twitter de Plutoo  

Il n'y a pas que les consoles modernes qui voient arriver de nouveaux exploits, voilà que c'est la Nintendo DSi qui voit passer un exploit bootcode débarqué sous le nom d'Unlaunch.dsi.           Attention avant de commencer sachez que les versions s’enchaînent hier, le logiciel était disponible en v0.5, et ce matin voilà déjà la v0.6 et tout cela est disponible en version bêta et est encore assez instable, vous pouvez bricker facilement votre console, il est conseillé d'avoir un backup eMMMC et un hardmod d'installé si vous souhaitez tenter l'expérience.   Unlaunch.dsi est le premier exploit bootcode publié pour les consoles DSi, il se base sur un contrôle des droits d'accès SCFG_EXT complets immédiatement après l'allumage de la console, avant même de démarrer le lanceur.   L'installation nécessite un exploit DSiware fonctionnant avec un accès SD / MMC, ou un hardmod, il marche sur toutes les DSi, quelle que soit la région ou le firmware.   Une fois installé, il démarrera le fichier 'bootcode.dsi' présent sur la carte SD si elle est présente, dans le cas contraire, il redémarrera le lanceur de Nintendo (avec des fonctions de sécurité et bootmusic perturbées, supprimera les contrôles RSA, la liste blanche et les paramètres de région).             Encore une fois, cet exploit est très sensible, il implique la modification TMD de la NAND, il est fortement conseillé d'attendre la sortie de RocketLauncher.   De plus, si vous installez ou utilisez cet exploit, vous n'aurez plus la possibilité d'utiliser la DSi Shop ou 3DS Transfer Tool sous peine de brick.   Pour la petite histoire, les images de fonds GIF utilisées montrent Herzogin Cecilie. L'auteur a également considéré que Principessa Jolanda, un paquebot qui a chaviré dès son lancement en 1904, pouvait servir de background pour cet exploit.      Téléchargement : unlaunch.dsi v0.6 (24.04.2018)  

Une nouvelle fois la Team Fail0verflow vient faire trembler le monde des consoles, en s'attaquant désormais à la Nintendo Switch elle frappe encore les esprits. La scène Switch évolue enfin, après l'arrivée du leak du bootrom, puis celle du launcher fusée, et l'avancement sur Atmosphère, la Team Fail0verflow quand à elle propose son implémentation du hack, et les outils permettant le portage de Linux pour Nintendo Switch.   Le hack est compatible avec toutes les Switch, le firmware n'a pas d'importance. La Team avait l'intention de l'intention de libérer tout cela le 25 Avril, mais le leak a accéléré la sortie.   Ce hack est basé sur le mode de recovery USB du Tegra, aussi appelé mode RCM, la vulnérabilité utilisée est la même que celle expliquée par Kate Temkin pour Fusée Gelée.           Pour la mise en oeuvre, il faut démarrer la console en mode recovery, pour cela il faut maintenir le bouton de volume sur haut, tout en appuyant sur Home et Power, tout en connectant en USB à un PC pour injecter l'exploit, cela ressemble fortement à ce que l'on fait sur un smarphone ou une tablette pour customiser les bootroms.             L'exploit Coolbot de la Team Fail0verflow se nomme ShofEL2, il s'agit d'un ensemble d'outils pour lancer Linux, et ainsi parvenir à lancer des jeux Gamecube sur Nintendo Switch par l'exploitation de l'émulateur Dolphin, ou encore un émulateur Wii.             Même si l'exploit est publié, il doit être compilé et seul des utilisateurs expérimentés peuvent le faire, il s'agit là d'une volonté de la Team Fail0verflow qui protège l'usage de cet exploit. Il faut d'abord cloner 5 fichiers git, ensuite créer le loader cbfs, u-boot, coreboot, imx_usb_loader, créer sa build Linux et lancer l'exploit.     Tout est explique ici :   https://github.com/f...verflow/shofel2 https://github.com/f...rusted-firmware https://github.com/f...switch-coreboot https://github.com/f...w/switch-u-boot https://github.com/f...ow/switch-linux        

Les informations semblent se dévoiler désormais, la Team Reswitched montre enfin une grande majorité de son travail.   C'est désormais sans le moindre d'un doute que nous allons pouvoir lancer des payloads.bin comme cela est possible sur PlayStation 4.05 et 4.55.           Kate Temkin dévoile un document PDF qui explique l'intégralité du fonctionnement de Fusée Gelée.   Ainsi Kate explique comment le code se lance, et le document explique de façon détaillée la vulnérabilité utilisée, en fait on y découvre le writeup de l'exploit tout simplement.      Pour couronner le tout, elle fourni un exemple du payload.bin ici.     Tout est là en 12 pages : fusee_gelee_nvidia.pdf     Le Github de Fusée Gelée dévoile aussi énormément d'informations sur cet exploit.  

Depuis le leak du Tegra X1 Boot ROM, la team ReSwitched a décidé de publier sur github tout ce qui est nécessaire pour contribuer au développement de Atmosphère. 

 

 

 

Il semblerait que quelqu'un a trouvé, et documenté un de nos bugs bootROM. Vu qu'il n'y a plus vraiment de raison de le cacher, ReSwitched vous apporte : http://www.memecpy.com/. Aussi : JoyCon hack ? Toujours réel. Plus d'informations / guides en approche.

 

SciresM invite donc des développeurs à contribuer au développement de Atmosphère.

 

 

 

Bien, ceux qui sont intéressé peuvent maintenant contribuer au développement d'Atmosphère.

 

Pour cela il suffit juste de se rendre sur le Discord de la team ReSwitched et demander le grade hacker qui vous donne la permission d'accéder au channel "cfw-development". 

 

C'est une bonne nouvelle car tout cela va permettre à la scène Nintendo Switch d'avancer un peu plus rapidement.

 

 

Lien d'accès au serveur Discord : https://discord.gg/DThbZ7z

Le github de "fusee launcher" : https://github.com/r.../fusee-launcher

Manjaro Linux PS4 v2 est désormais disponible et intègre les derniers apports de la team Psxita et le dernier noyau Linux d'Eeply.

En toute logique, toutes les PS4 en firmware 4.05/4.55 (FAT/SLIM/PRO) devraient désormais pouvoir lancer et utiliser Manjaro Linux , que j'ai pré-configuré par défaut.
 
 

 
 
J'ai également ouvert une page de wiki sur laquelle tout le monde pourra se référer comme documentation spécifique à la PS4, et y contribuer.

Vous retrouverez la documentation et les liens de téléchargements ici => https://wiki.osremix...ation_4/manjaro


J'ai par ailleurs uploadé de multiples vidéos pour vous offrir un petit aperçu du rendu.

 

https://youtu.be/r7GdKHZ4210?t=315


Et pour être bien clair, les progrès apportés par les derniers patchs de la team Psxita sont très grands, mais on est encore loin d'exploiter le plein potentiel de la console du côté du GPU, il reste encore du travail, mais, c'est déjà un bon début, la scène homebrew s'ouvre désormais pleinement à la PS4 vu qu'il devient désormais possible d'utiliser et jouer à la plupart des émulateurs sans passer par l'émulateur PS2 intégré à OrbisOS.

De même, nous pouvons profiter de wine pour certains jeux PC, et de Steam sous Linux & Windows (via wine, toujours)

Il ne tient qu'à chacun d'apporter ce qu'il peut pour faire avancer la scène sur ce point.

Comme certains me l'avaient réclamé, j'ai également préinstallé RetroArch, avec de multiples cœurs d'émulateurs... Vous devriez avoir de quoi faire !

 

J'ai par ailleurs divisé en deux le fichier à restaurer, d'un côté la partition fat contenant le dernier noyau d'Eeply et l'initramfs qui boote sur Manjaro (FAT), de l'autre la partition système ext4.

J'ai pris cette décision afin que chacun puisse adapter la distribution à sa situation, et peut être qu'à terme un développeur trouvera le moyen de booter Linux depuis la PS4 sans devoir passer par un Payload.

 

 [EDIT : suite à la demande de certains, un fichier single est désormais disponible, compressé, ce dernier ne fait que 4Go)


Dans les vidéos, l'OS peut sembler un peu lent, mais en réalité c'est parce qu'il démarre depuis un disque dur externe, je vous conseille vivement d'utiliser un SSD + adaptateur SATA => USB 3.0 pour profiter pleinement de Linux sur votre console.

Le Boot ROM du Tegra X1 a été leaké, cela signifie que tout le monde peut maintenant profiter de éditeur hexadécimal pour regarder dans les failles pour parvenir à exploiter le boot du Tegra X1, c'est une solution plus large que la seule limitation à la Nintendo Switch.         Tous les appareils qui disposent d'une puce Tegra X1 sont concernés, pas "seulement" la Nintendo Switch. Le leak vient de la même personne qui a déjà dévoilé la master_key_03 il y a quelques jours.         La source prétend que comme le glitch est assez dur voilà le Tegra X1 Boot ROM. Pour le commun des utilisateurs, ce fichier bin de 96 Ko n'est pas très utile, les Fail0verflow et autre Reswitched avaient déjà ce document depuis des semaines.    Il manque tous les ipatches de nVidia et de Nintendo, mais seul le prochain Tegra X1 T214 viendra corriger cette faille sur le Tegra X1 T210 présent dans la console de Nintendo encore un bon moment.    Tout est là : Tegra X1 Boot ROM  

Une fois n'est pas coutume, nous pouvons un peu repartir du côté des verts avec une petite news pour la console de Microsoft, même si cela ne concerne pas directement le hack, il est quand même intéressant pour ceux qui disposent d'une console Xbox de savoir ce que le prochain firmware apportera.          La première innovation qui sera intégré dans le prochain firmware est le support des écrans et moniteurs 120 Hz en résolution 1080p et 1440p. La seconde nouveauté est la possibilité de personnaliser des groupes dans lesquels on pourra classer des jeux et des applications avec la capacité de les ajouter à l'écran principal.             D'autres évolutions porteront sur le contrôle parental, ou encore la possibilité de couper des vidéos clips directement dans le guide. L'app de gestion des accessoires a été revue et elle serait plus intuitive.         Pour profiter de cette update en avant première, il faut être inscrit comme Xbox Insider, sinon il vous faudra patienter jusqu'à la sortie de ce nouveau firmware.      Source:  Dualshockers.com  

Nous vous l'annoncions hier, le voilà déjà ! Le développeur Shiny Quagsire a publié le code source de Arch Linux pour le lancer sur la Nintendo Switch.              Attention, il y a très peu de pilotes portés pour la console, donc vous ne pouvez pas vous servir des ports USB, du WiFi, du Bluetooth, le tactile ou de l'audio.         Pour pouvoir exécuter Arch Linux vous devez avoir accès à un exploit TrustZone ou Bootrom, ils ne sont pas officiellement disponibles au public, mais pour retrouver le code de cette distribution cela se passe par ici : ArchMinux ARM.

 

 

 

  Requirements u-boot running from either TrustZone takeover or bootrom hax. Neither is provided currently, however Switch-compatible u-boot can be found here A properly-formatted SD card. Instructions can be found below in Compiling, Installation and Setup Notes on PSCI Nintendo's Horizon OS TrustZone component can provide PSCI calls which work for Linux (given patches provided on the repo). By default, the device tree is configured for Linux running from u-boot packaged in Nintendo's package2, with all PSCI calls being sent to SMC #1 instead of SMC #0. Use of other trusted firmwares with PSCI on SMC #0 should be able to remove the need for these patches, however it is untested currently. Notes on debugging By default, the right Joy-Con rail is used for UART logging output, with pin 5 being the console's TX, and pin 8 being the console's RX. See here for details. Compiling, Installation and Setup

Installation of u-boot will depend on loading methods used. However once u-boot is installed, the following instructions can be used:

Make sure your SD card is formatted with MBR partitioning, with the first partition being FAT32/exFAT and a second for ext3/ext4. If ext4 has issues booting, try ext3. Download the generic ALARM image here and follow the instructions provided to install the filesystem to the ext3/ext4 filesystem on your SD card. You may need a Linux box to do these steps. Clone linux-next using git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git cd linux-next && git checkout v4.15 Apply the provided patches in the repo using git am -3 -k <patch file> NVIDIA has microcode required for their host1x/DRM subsystems. This should be compiled into the kernel or initramfs for early screen init. Download the linux-firmware package from here mkdir extra_firmware Copy nvidia/tegra210/vic04_ucode.bin and nvidia/tegra210/xusb.bin from the package to linux-next/extra_firmware/nvidia/tegra210/vic04_ucode.bin and linux-next/extra_firmware/nvidia/tegra210/xusb.bin It should be noted that while this may be useful for easy debugging, generated kernel images will be dirty and not strictly GPL compliant. It is recommended that, for image-based releases, that these files be installed to the initramfs. TODO: It might be better to just not have an initramfs and have these pulled from the actual root partition, with linux-firmware installed to it. Ensure that you have an AArch64 cross-compiler installed. export ARCH=arm64 export CROSS_COMPILE=aarch64-linux-gnu- mkdir -p build/hac-001/ make O=build/hac-001/ hac_defconfig make O=build/hac-001/ -j4 Image Copy the Image file from build/hac-001/arch/arm64/boot/Image to the boot/ folder on your SD card's FAT partition. In this repo, mkimage -A arm -T script -O linux -d u-boot/boot.txt u-boot/boot.scr and copy boot.scr to the boot/directory on the FAT partition of your SD card. make O=build/hac-001/ -j4 modules make O=build/hac-001/ modules_install INSTALL_MOD_PATH=/path/to/ALARM/rootfs/, you may need to run as root (with environment variables set again). ALARM has a default initramfs which needs to be wrapped for u-boot. mkimage -T ramdisk -C gzip -d /path/to/initramfs-linux.img /path/to/FAT/boot/initramfs.uImage In the repo, cd device-tree && sh build.sh && cp tegra210-hac-001.dtb /path/to/FAT/boot/ Your FAT boot/ directory should have Image, initramfs.uImage, and tegra210-hac-001.dtb Boot through u-boot. If an error has occurred, it will open a USB mass storage device for the SD card.