 Bonjour tout le monde, je pense que l'on peut commencer. Nous allons voir ce qui est nouveau, signé la dernière fois. Nous avons fait une checkliste de l'armes linux. D'abord, j'introduise moi-même. Je suis Gregory Clément, j'ai travaillé à Free Electron, où nous faisons le développement basé sur l'opinion. Et moi-même, j'ai été un contributaire sur le support de Kierner pour les nombreux SOC Marvel et récemment sur les 64 bits SOC, les Armada 3700. Et j'ai aussi un commentateur de l'architecture de Marvel ABU. Il y a quelques bas-d'articles sur ce talk et l'armes 64. En décembre 2012, il y a eu le support de l'armes 64 bits, qui était marge dans le Kierner 3.7. Donc, c'était le premier coup. À ce point, il n'y avait pas de réel hardware. Et il n'y avait que quelques mois plus tard qu'il y avait le support pour le premier armes 64 SOC. Et il n'y avait que un an plus tard qu'il y avait le support pour le second armes 64 SOC dans le Kierner 3.18. Et ce temps, c'était le maintien de l'armes 64. Donc, la première question est pourquoi cette nouvelle architecture. Normalement, c'est une nouvelle création et un processus de développement. Mais l'armes 64 est encore une architecture. Et ce talk est une attente de summariser des différences et des similarities avec l'armes 32 bits et d'accompagner une ligne pour aider les développeurs pour nouveaux armes 64 bits pour les mettre en place dans le Kierner. Mais ça peut être aussi utile si vous voulez juste poursuivre l'armes 64 sur le Kierner. Partage de ce talk sera basé sur le talk de Thomas 3 ans plus tard. Mais nous allons s'occuper de l'armes 64 et aussi il y a des updates entre l'armes 64 et l'armes 32. Alors, nous allons voir la différence entre l'armes 32 bits et l'armes 64 bits. Donc, dans le Kierner, l'armes 32 bits est de l'armes V4 à l'armes V7. Mais l'armes 64 bits est en fait un mode de l'armes V8. Et l'armes V8 est aussi capable d'aller dans l'armes 32 bits. Et le nom de l'armes 64 bits est Arch 64. Mais à la fin, dans le Kierner nous préférons l'armes 64. L'armes 64 vient évidemment d'avoir le support de l'armes 64 bits mais aussi avec l'instruction virtualisation et d'autres improvements. Donc, ce nouveau architecteur n'a pas été rendu avec l'armes 32 bits et il y a quelques questions sur cela au début. La première raison est que le code d'assemblage est différent. L'interface système est différente, elle utilise un nouveau API. Et puis, maintenant, la plupart des supports de plateformes pour l'armes 32 bits ont déjà évoqué dans le chauffeur et même l'infrastructure qui pourrait être commun entre l'armes 32 bits et l'armes 64 bits devra aussi aller au-delà de l'architecture d'article 32. Donc, c'est pourquoi j'ai aimé partager le même directeur et une autre raison aussi c'est l'aide à commencer d'une nouvelle implementation sans avoir de support de plateformes legacy. La première importante c'est que si vous voulez mettre de support pour votre nouveau l'armes 64 bit sur la mainline C'est-à-dire que Catherine Marinasse et Will Deacon sont les maintenance pour les supports de l'armes 64 et actuellement il y a quelques raisons que vous devez envoyer direct pour eux si vous justifisez un nouveau l'armes SOC surtout si vous utilisez déjà un contexte de l'armes. La mainline et la mainline de Johnston sont les maintenance de l'armes SOC et tout le code de l'armes 64 doit aller au-delà et ils assurent la consistance entre les problèmes de l'armes 64 et de l'armes 64 et de l'armes 64 c'était Catherine et Will mais avec plus de support de la mainline et aussi avec des problèmes communs avec le support de l'armes de l'armes il y a la mainline et bien sûr vous devez aussi interpréter avec les maintenance de l'armes ici est la liste de leurs si vous avez un look sur ce que nous avons fait il y a 3 ans il y a quelques différences mais pas beaucoup peut-être dans l'aéroport il y a un nouveau maintenance et dans l'armes 2 si vous voulez savoir où est le code et quand pour cette partie il n'y a pas de changement mais nous allons le voir donc la liste de l'armes est sur le canal.org dans la prochaine partie vous avez ce qu'il y a par la liste de l'armes durant la prochaine mainline et généralement c'est toujours vrai le maintenance de l'armes veut avoir tout le code deux semaines auparavant ils veulent avoir tout pour la liste de l'armes de l'armes bien sûr si il y a un petit changement ils peuvent le prendre mais si vous voulez faire une première mission au moins vous devez le faire deux semaines auparavant l'armes s'ouvre si vous soumettez votre code durant l'armes et il n'y a aucun moyen de l'intégrer dans la prochaine phase donc vous devez attendre pour la prochaine et la liste de l'armes de l'armes les gens vont faire commenter sur votre code vous devez les prendre en compte et trouver la bonne balance entre les patients et les patients donc vous devez l'interpréter avant d'interpréter mais vous n'avez pas de temps aussi pour l'existence de code il y a un changement d'actualité dans ces derniers talks Thomas dit qu'il y avait 19% que vous devez le poursuivre et maintenant c'est un peu mieux je pense que c'est une chance que vous devez le poursuivre donc la plupart du temps c'est parce que le code de l'armes de l'armes ne complique pas avec les règles de code Linux ils ne respectent pas l'infrastructure Linux et ils ont un soucis major pour l'armes 64 le port est assez nouveau et donc ce vendeur de l'armes n'a pas de temps pour être trop créatif il n'y a pas de choses horribles en fait et même pour les vendeurs de l'armes certains d'entre eux ont réduit la gaffe entre les 3 internes et les main-laces donc il y a encore des différences mais c'est devenu mieux et certains d'entre eux restent encore sur une très toute faissure de l'armes qui prédate pour le device 3 et prédate pour tout le système et puis pour dans ce cas vous pouvez juste mettre le code mais encore, vous pouvez l'utiliser comme référence pour vérifier comment ça peut fonctionner comment interagir avec le SOC parce que parfois la seule documentation que vous avez sur comment le SOC fonctionne sera le code même si le code est agréable sur le TPD donc la première étape c'est de commencer minimal maintenant pour l'armes 64 c'est assez straightforward il n'y a pas beaucoup de choses à faire le plus important sera le device 3 puis vous avez besoin un timer, un contrôleur et bien sûr un port et si vous êtes heureux c'est ça donc maintenant je pense que vous connaissez ce que le device 3 est c'est pour faire une abstraction de ce que l'armes est c'est pour décrire l'armes sur le code donc cette structure compile dans un binary qui s'appelle device 3 blob ce blob est installé par le bootloader et passe au canal déco-edit et puis obtient la ressource l'usage de ce device 3 est monatérien pour tous les armes donc le nouveau armes 32 bits et le nouveau armes 64 bits et pour l'armes 64 c'est la seule partie qui va dans l'armes 64 le seul code que vous allez écrire et mettre sous ce système c'est le device 3 pour écrire le device 3 généralement vous utilisez un file DTSI qui décrive le SOC et puis vous avez votre file DTS pour votre board et pour votre board vous inclurez plusieurs DTSI de la partie que vous avez si vous voulez ajouter votre board vous devez avoir un nouvel de compile donc dans le file Mac located dans votre DTS vous devez modifier le file Mac pour ajouter un nouveau entier pour compilier votre board et la main différence avec l'armes Hatch c'est l'utilisation d'un directeur de vendeur donc pour l'armes 32 bits tous les files de device 3 sont located dans Hatch Arm Boot DTS alors que pour l'armes 64 c'est Hatch Arm 64 boot le nom du vendeur et votre file de device 3 donc un exemple simple pour Armada 3700 3700 donc nous avons un file de command pour tous les fonds de la famille et puis chaque SOC a sa propre DTSI à la fin vous avez quelques boards qui peuvent inclurez ce file de command et dans ce file de board vous décriverez qui est spécifique pour votre board vous déclarez ce contrôleur vous utilisez il est connecté à ce nouveau external chip et tout un autre exemple donc ici c'est un part de un file de DTSI donc vous décriverez le SOC donc vous avez un note pour les CPUs pour le TIC le timer et puis c'est ici que vous mettez tous les contrôleurs inclus dans votre SOC et puis dans votre DTS vous avez juste dit que ici c'est très simple parce qu'ils font la choisie d'améliorer l'Europe par défaut vous devriez déterminer tous les contrôleurs par défaut dans votre DTSI et c'est seulement dans votre DTS que vous avez dit que je veux celui-ci et donc généralement vous avez un statut d'amélioration je veux activer ce contrôleur pour celui-ci et la seule chose que vous avez c'est la mémoire que vous avez et pour votre porte vous vous printerez votre canon et ainsi sur ARM64 il n'y a pas de Mac et c'est une différence que vous avez dans ARM32 pour chaque nouvelle SOC vous avez un Mac ici vous n'avez pas de ce genre de choses donc vous avez des avec de la la la et si la feature ne peut pas être un ordinateur par défaut de� je ne suis pas sûr que cela fasse une certaine des codes communs pour la famille de SOC dans cet endroit. Un autre file que vous devez modifier est la plateforme KCONFIG. C'est un endroit où, quand vous configurez votre kernel, vous pouvez sélectionner le support de votre SOC. Si vous comparez avec le KCONFIG pour l'armes 32-bit SOC, il n'y a plus de KCONFIG symboles, parce que maintenant, beaucoup de symboles sont par défaut. Quand vous sélectionnez l'armes 64, il y a beaucoup de symboles. Le support de l'armes 32-bit SOC est... Parce que la première chose que vous voulez avoir quand vous commencez à apporter de votre SOC, une nouvelle SOC, c'est d'avoir un signe, d'avoir une façon d'avoir l'armes 32-bit SOC et pour l'armes, c'était Eury Prinka, qui a été utilisé. Pour celui-ci, vous devez installer l'adresse de l'armes EURAT très rapidement dans le boot. C'est à dire que, quand vous utilisez Eury Prinka, vous n'êtes pas capable d'avoir la même image de KCONFIG sur une autre sorte de SOC, parce que vous avez apporté l'adresse physique de l'armes EURAT. C'est pourquoi, pour l'armes 64, ce n'est pas encore le cas. Vous devez utiliser Heurlicone. Donc, ce n'est pas à l'arrivée de l'armes, c'est à l'arrivée de l'arrivée de l'armes Serial. C'est en fait partie du support de l'aéroport et dans l'arrivée, il est déclaré d'utiliser Heurlicone déclaré, ou OF Heurlicone déclaré. Pour le support de l'aéroport, donc si votre plateforme utilise GIC V3, V2 ou V3, et votre contrôleur, alors il y a déjà un driver dans l'aéroport d'armes, donc vous n'avez pas à faire tout ça. D'ailleurs, vous devez impliquer un nouveau à la même location. Et, cette partie ne change pas de la dernière fois, donc vous devez toujours supporter le support de l'aéroport. Vous devez aussi supporter le multi-aéroport. Et si vous pour l'armes 32 bit machine, vous devez utiliser DT Machine Start et ici, utilisez Inetire Q. Et pour armes 64, vous avez juste à installer ce nouveau DTS file. Et, ceci est aussi vrai pour armes 32 bit SOC. Pour l'armes timer, donc, cette partie doit être impliquée dans l'armes clock source. Elle doit régister un device clock source, qui est utilisé un timer prévenu avec l'armes prévenue à l'aéroport pour maintenir le track de l'armes passée. Donc, selon ce que vous utilisez dans votre SOC, vous pouvez utiliser l'armes clock source ou une solution moderne qui est l'armes clock source register HZ. Vous devez aussi régister un device clock prévenu pour programmer le timer. Vous pouvez aussi programmer si vous pouvez le délai, c'est mieux d'avoir le timer basé sur le loop sur le canal. Et aussi pour l'article d'armes qui ont un délai et il doit être essentiel dans votre GTSI. La dernière partie est l'aéroport. Donc aujourd'hui l'armes et l'armes 64 SOC utilisent l'Azer IT 250 compatible URAT ou PL 11 URAT controller pour l'armes. Donc dans tous les cas vous avez déjà Linux driver donc vous n'avez rien à faire. Vous juste besoin d'installer votre GTSI et marquer l'available en utilisant un status equal OK dans votre controller URAT. Et puis vous devez faire plus de choses. Vous devez mettre un complet driver de scratch et même pour une très nouvelle SOC, par exemple l'un de l'aéroport armes 64 SOC ils ont besoin de créer un nouveau controller pour URAT. Donc vous devez faire un controller et votre driver dans le canal. Mais vous pouvez commencer très simple au début vous n'avez pas besoin de soutenir toutes les choses que le design hardware peut ajouter si vous voulez juste faire un appareil vous devez avoir un sens pour envoyer le data sur la ligne et lire le data et c'est tout. Et n'oubliez pas d'inclure l'appareil pour vous d'avoir le début du canal. Et pour cette partie la machine est Greg Quartman. Donc à la fin de la étape 1 à ce point votre système doit mettre tous les lois pour un shell donc c'est possible que vous n'avez pas d'intérêts mais vous pouvez mettre dans un minimum d'outil d'utilisation d'intérêts pas que le canal ne compresse elle-même donc si il n'y a pas de support dans le bootloader 2 alors l'image pour le load peut être très grande autour de 20 megabytes où les cannelles sont utilisées et donc à ce point c'est le temps de mettre votre base ARM64 de support et n'oubliez pas d'avoir tout le driver et tout le futur c'est mieux spécialement pour la première émission vous allez avoir des revues peut-être des changements pour faire donc c'est mieux de changer d'un début donc comme je l'ai dit si on y retourne là-bas ok, là-bas donc et c'est probablement ok si vous utilisez un contexte quelque chose de harm et utilisez un compatible driver c'est possible que vous avez déjà le driver timer déjà cette et cette donc vous pouvez commencer par juste écrire un dévice si votre SOC n'est pas trop exotique puis la étape 2 est d'avoir l'infrastructure pour votre SOC donc la pincée le GPIO et les clocks parce que jusqu'à maintenant c'est roulant mais vous vous rappeliez sur ce que j'ai fait dans le bootloader vous vous rappeliez mais sur le fait que le bootloader a commencé les clocks j'ai set-up la pincée pour vous donc ça va fonctionner mais dès que vous voulez changer quelque chose du bootloader ou si vous voulez revenir de la pincée ou quelque chose comme ça vous avez besoin d'une meilleure infrastructure donc la framework a été modifiée cette framework implementa le clock get clock boot et so on c'était l'IP usage pour le driver et implementa un basic clock driver fix rate gattable et un nouveau et allow l'implimation de votre custom clock driver c'est aussi pour les clocks et comment c'est associé à la devise dans la devise 3 pour les clocks 3 ils sont implementés dans le clock driver donc si vous voulez voir j'ai un choc 3 ans donc la pdf est disponible et il y a une vidéo et les nômes sont très peu et les clocks sont consommés donc c'est un programme plus fixable ou en faire un programme apportant des parties à avoir un worshiper par ce d'une mode, c'est plus flexible pour vous de changer. Et aussi, c'est quelque chose qui est demandé par les maintenance de l'éclat. Donc, ceci est assez nouveau. C'est le plus différent entre les derniers paroles. Donc, quelques exemples sur le côté de l'aéroport. Donc, sur le côté de l'aéroport, généralement, dans le probe, vous obtenez votre référence sur l'éclat. Et puis, quand vous commencez, vous enlèvez votre cloc. Pour ce que vous êtes ici, vous avez aussi besoin de l'éclat. Et quand vous voulez chier votre système, vous pouvez juste éclater votre cloc. Et quand vous finissez avec votre chauffeur, vous pouvez retirer votre cloc avec l'éclat. Mais maintenant, il y a aussi l'application managée sur l'éclat. Donc, si vous utilisez juste le cloc de la dévm, vous n'avez pas besoin de l'éclat. Il sera fait directement par le canal pour vous. À l'éclat de l'éclat, vous pouvez avoir quelques clés qui sont plus fixés. Vous ne vous reliez pas sur un registre. Donc, il y a le cloc de la dévm. Et puis, après, le vrai chauffeur, qui dépend de l'éclat, est associé à l'éclat. Et aussi, vous avez toujours un cloc qui dépend de l'éclat, pour avoir une présentation de votre cloc de la dévm. Et maintenant, comment une dévm peut utiliser l'éclat ? C'est juste ici, un cloc et une référence sur votre cloc. Donc ici, c'est un cloc qui expose beaucoup de clocs différents. Donc, c'est pourquoi nous avons un cloc de celles de l'éclat. Donc, ça veut dire que vous pouvez avoir plusieurs clés ici. Donc ici, nous avons une référence sur l'éclat. Et ici, c'est un numéro pour dire quel cloc de l'éclat qu'on veut utiliser. Maintenant, une petite picture de ce que c'est. Donc, nous avons le cloc de la dévm. C'est accès par l'éclat de l'éclat de l'éclat de l'éclat de l'éclat public. Le cloc de l'éclat de l'éclat de l'éclat et de l'éclat de l'éclat. Et le cloc de l'éclat de l'éclat utilise l'éclat de l'éclat. Donc, certaines d'elles sont offertes par l'éclat de l'éclat. Et certaines d'elles, vous devez les dévumer si vous ne pouvez pas utiliser le basique. Et une autre partie de l'infrastructure de l'SOC est la pince de l'éclat. Donc, le besoin de pince de l'éclat est parce que le stock intégrerait beaucoup plus de pince. C'est le nombre de pince disponibles que l'on peut exposer. So, many of those pince are multiplexed and they can either be used by a function A or a function B or C or GPIO, for example. For example, for the function can be parallel LCD line, SDA, SCL lines for the high square cibus, MISO and MOSI for SPI and so on. So, this mixing is software configurable and depends on how the stock is used on a particular board. So, it's really depend of the design of your board and how the hardware designer decides to use the function, the feature of your SOC. So, here's a small principle. So, we have several blocks which share only two pins and depending of your function you can map them on a function or another function. So, the, why, it's not so new now, but the pin control system is here to solve this problem. It is developed and maintained by Linus Follage and it is implemented in its driver pin control and so it provides an IPI for the driver. So, an IPI to develop the device as a pin control driver and an IPI to use this pin control from the driver. It also offers an interaction with the GPIO framework. So, you see more or less the same thing. The main difference between the clock framework is that you also have a relationship with the GPIO driver which can also embed an IRQ chip driver and GPIO chip driver. So, how you declare them. So, at your device 3 level, you declare them by, for each group of pin, you declare them as groups and as functions you can use. Something more or less new for it is, until recently, each implementation has its own name. So, you had a Marvel group, you have some 6C group and so on. And now, it's better to try to use the common name from the pin control system. And so, when you want to use it, for example, on the Android DC2 DTS5 as a board. So, you said that you want to use this configuration and it was the one which will be used by default. Not that in this case, if you use the default one, at the driver level, you don't have to do anything. It's a framework which, take care of, use the default one. But if on your driver level, if you want to use a specific configuration, then you can use the pin control API. But if you just want to use the one set by the DTS, you don't have to add anything new at your driver. So, the GPO driver is the last point you can develop. And it now must be in driver GPIO. And if the GPO pin can be mixed, then it must interact with the pin control system to get the proper mixing. Yes, it's not the common things to do, but you can have some components, like you said, for program management or something like that, where you want to change the pin control behavior. Or, for example, you can do it also for the FPGA. If you want to load the FPGA on the fly, you change the behavior of your pin because they are going to be connecting in a different way to your FPGA. So, you change the behavior of the pin you have at this time. So, it can be a usage for it. So, it's the end of the step two. And then, from step three, you are going to develop more advanced features and more drivers. And so, it can be a natural driver, API driver. But here, it's less something related to architecture. It's just developing driver. However, there is something specific to the ARM system. First thing, each device driver must have a device rebranding. A binding describes a compatible string and the property that a DT node must carry. And this binding also must be documented in device rebindings. And some particular things for the 64-bit support. So, most of the ARM64 SoC reuse driver developed for the ARM32 bits. The driver supposed to be portable. But, until recently, they were only used on 32-bit architecture. There are some bugs that could have been missed. And so, you have ready to pay attention with it. For example, you will punch her to cast pointer. Like until now, you just can't do a void star and it was okay. And there is no problem. Now, you have to do it. Also, you have to pay attention that peripheral bus can have a smaller size than the CPU bus. On peripheral ICs, they still use 32-bit bus when you want to address them. So, you still use writeL or readL, for example. And the data size you want to use is you have to really specify that is U32 or E32 so that it will match the size of your physical bus of your peripheral. So, conclusion. The code in ARM64 tree is cleaner than the one in SoC. But it benefits on all the constellation done on ARM. So, there is a lot of work which has been done on ARM which will also be done with ARM64 in mind. But you get the best of the ARM without having to deal with all the legacy code. And that means that adding an initial support for new ARM64 SoC needs very few lines of code now. So, as I said, if you are lucky, the specific part of ARM64 is very few. Just a few lines of DTS file. And a few on tree is a make file of the DTS. And a few lines in the care config and that all. If you use, for example, a Cortex-A53, for example. However, there are still some... It's also because some of the complexity now is hidden in a firmware, the ACPI or PSCI. And the power management is still changing. There is still a code which remains in ARM which is related to the power management. And one solution for ARM64 is to not have a very less code inside the kernel but just inside a firmware. So, that's a way to have less complexity inside the kernel but it's put just behind a firmware. So, if you have any question? No? Yes? You mentioned your timer. Yes, it's only... That's why, as I said, if you use a Cortex-something which came with an Arch Timer, then you don't have to develop one. It depends on your SoC and of what you use. There are still some ARM V8 SoC which don't use a Cortex-something. I think there is one from Tigra or it's still possible to have some SoC which don't use the Cortex so we don't come with a timer. You can also have multiple timers in one SoC. For example, on Armada one, we have also the legacy timer which is still present. So, of course, we don't use them for the initial port but we can use them for other usage. It's still the case. It's the case for all the ARM SoC. Yes? For the engineers support, so the ARM kernel is supposed to support it. However, I know that Ben Dukes do a lot of work around it and even if at the kernel level it should be okay, he found a lot of issues in the driver for the same reason that you have issues when you switch from 32 bits to 64 bits, you're supposed to be portable so you're supposed to pay attention on DNS but as it was not test in this big Indian case you have a lot of issues about it but there is no real problem about it. You just have to check that the driver you want to use don't make some assumption of being a little Indian or a big Indian. Do you have a question? Yes? It depends on what you want to use. If you want to use a mainline kernel, you have to use the DTSI defined in the mainline kernel and the DTSI is really supposed to describe the hardware so you can't change it. You can add something, is the DTSI, there is some missing part or maybe there are some bugs. Yes, so you include your DTSI which represents your SOC. Now you will have to put it in the vendor directory. Yes. Just a way to TD the file is not really... Just to say that you are going to use this SOC so your board will be close to this SOC No more questions? Thank you.