ARM boards update
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Färber, Andreas
This talk will follow-up on the corresponding 2016 talk with an update on new ARM boards enabled in openSUSE.
 So, hello. My name is Andreas Verba and I will be giving a status update on what's been happening with the OpenSuser ARM port in particular in terms of hardware support. Let's start with a small disclaimer. So, I will be talking about hardware in this talk, but this is not supposed to be a guide for actually buying hardware. I will not be going into much details of the hardware, but rather into the state of what the software is looking like and where currently things are working and where things are not yet working so well. Initially, I will be going through the various number of boards grouped by the architecture that they are using. Afterwards, you can kind of think of this as covering two dimensions. So, on the one hand, they keep new boards keep coming up and new boards keep getting enabled for OpenSuser as well then, but on the other hand, there is not just drivers getting added for boards, but obviously, there's things that you may actually want to do with a board once you have it booting. So, you may want to connect additional pieces of hardware for it and I will go briefly into that topic at the end as well as covering some work for actually building software for ARM. Additionally, on your right-hand side, stage left, you will see a number of boards that I will be talking about later on here. So, feel free to walk there either during the talk or after the talk and let's get started now. One key piece that we always need when we are dealing with ARM boards is information. That's something that in some cases is lacking in some other cases where more people are using it is more widely available. So basically, you need to know what you need to put on a particular medium to actually make the hardware boot. You don't have a bias usually on there, not in a UEFI firmware either on most non-server boards for the community. So you may need to actually do something to get it to show something on the screen or on the serial cable. And if you do not have such an advanced server firmware that provides ECPI tables even, then you also need a so-called device tree. Next question then is, does the Linux kernel, in particular the OpenZoozer kernel already contain drivers for the various peripherals of the chip that is located on your board and not just for the system on chip itself but also for power supply and various other possibly board specific parts? It may be possible that a generic juice image or DVD image can actually boot if the board has UEFI. If that is the case, then you're all set. However, if not, and this is going to be the majority of the cases I'm going to cover next, then you're going to need an image that is tailored to that particular board. When preparing an image for a board that no one else before you has enabled, then you will have to take care of two stages. So in particular, you have to make sure that the initial in-it RD contains all the driver modules that are needed for the board to come up to the actual Routefes. If you have the installation in DVD, basically that step is not relevant. However, you still need to make sure that also in the second step, then the in-it RD that is generated from within the running system also contains again all those modules to boot for the second time again. So basically that may require doing some tweaks for drag-with-config. As I already mentioned, not so many boards by numbers that are out there actually contain the UEFI firmware on some flash chip on the board. If that is not the case, then you need such a just enough operating system image, for example, to get started or some customized image with an additional software that you actually want to run there as an appliance. However, we have found that this does not scale very well, so basically on the one hand, it takes time to find out how do we actually boot on a particular board. Then all the necessary packages need to be accepted into factory. If that needs to build, building that also takes time and resources, and the number of onboard keeps growing. In previous talks at last year's Open Thusa conference here at this stage and at various other events, Alexander Graf has been presenting work for making the UBoot bootloader implement the UEFI specification to some degree. The idea with that is that going forward now, we actually want to move towards generic installation images or generic juice images rather than board specific images. The idea here is that we would like to split the firmware parts from the operating system parts on the other hand. That then leaves the question where would users actually then get the non-generic pieces of the firmware to actually boot to such a point. For that, obviously, OBS seems like a really nice fit where we're already doing this to some degree. However, we're still seeing some issues that Kiwi simply assumes that you have a relatively standard Linux configuration and that you have a boot partition or a root of S partition on there with lots of files being populated from packages, which would actually not be necessary for a pure firmware image. That is basically where we're currently headed as a prerequisite to what you're going to hear next. Let's start with the oldest generation, ARMv6. We already had the Raspberry Pi 1 model B working with Tumbleweed last year. What's been new is that the Raspberry Pi Zero is no longer a theory that no one can actually purchase, but it's actually possible to get your hands on one by now, at least in some regions of the world. Basically, the same Huboot package that we're using on the Raspberry Pi 1 is also working for the Raspberry Pi Zero, as well as the kernel and the juice image can simply be reused and are actually working, including the UEFI support. Even newer now is the ZeroW, which has an additional wireless chip on there. Unfortunately, this is not working at all. Basically, you don't even get serial output from Huboot. At this point, there is neither a DTS file available nor any work on that device yet. Does anyone here in the audience happen to have one? Okay. A few hands. If you find anything out about that, make sure to let us know. But at this point, unfortunately, OpenSUSE is not yet running on there. Moving on to ARMv7 then. In particular here, I'm very proud to present that we have another contribution by a community member, Frank Kunz. He had this DE0 NanoSock board with a Cyclone 5 SOC, and he's packaged Huboot to run on there, and UEFI just happened to work on there out of the box. I believe he's using the kernel default because, obviously, kernel LPE wouldn't work. There is a factory image with the name here that you'll just have to read for yourself. Basically, this is all working in OpenSUSE at humbleweed by now. Thank you very much. And an update on the Firefly RK3288. There has been a bit of fluctuation on which Huboot versions actually boot on it. The current version in factory 2017.05 is working again. I did have the kernel LPE image booting on there, but unfortunately, we haven't been able to get the juice image working. It simply, I think, it gets stuck during early code already. Similarly, oh, no, sorry, I mixed those up. So basically, the Firefly gets to a point where devices actually are starting to get enumerated and loaded on serial. So basically, there's probably some modules missing in the INEAD RD. Then a few people have been asking about the Tinko board. This is a board using the very same chip, but in a Raspberry Pi form factor by ASUS. And we do have Huboot working on there, but unfortunately, in this case, the juice image is stuck in early con because this uses a different power management IC. So basically, either some modules are still missing in there, or we may need to change some modules to build in for there. Does anyone in the audience here today happen to have one? Okay. Then some users had asked for the Mewdo Neo board. There is a Huboot package for that now. I also prepared a juice image, but it is getting beyond the INEAD RD. However, it hangs at some point, I think, after Etnavive is initialized. So either it's an issue between the various models of the Eudonio basic board or some pinmuxing or some other setting in the device tree might be wrong. Then an update on the guitar module. Last time I reported that basically nothing was mainline and openZoozer was not running on there. This is still the case at this point. However, I sat down and started writing patches in order to boot a mainline kernel on there, and at this point it's possible to boot into an INEAD RD, but not yet further because drivers for SD card and other devices like USB are still missing. The Nenopinio is one of several Sanji devices based on the H3 SOC. We have a package in factory since recently, but now that is actually booting. Unfortunately, as for most of all Windows devices, UEFI support is not yet working inside UBoot. So if anyone has such devices, I'm pretty sure there will be someone listening to this talk. We need people that actually sit down and debug why that is, adding some debug statements to UBoot and possibly adding some memory reservations to make that work. We have an image available. It boots everything, worked out of the box surprisingly for once. That was a really nice experience. However, some users actually wanted not the Neo, but the Neo Air to work, and that is still not working. So we have an Nenopinio Air package by now. However, the kernel does not have the device tree. So the question is, does the device tree that is contained in UBoot is sufficient for that? And unfortunately, I did not yet get feedback from the community on whether that is the case. So if you have such a board, please let us know. If you tell us that it actually works, then we can enable that and choose image in Tumbleweed. Another board of that same family, which by the way you can all see over there on the tables, is the M1 plus. Based on the M1 design, as far as I understand, and adds Wi-Fi on top of that. There were some patches for the M1 model, but no work for the M1 plus at this point yet. So if we get time, we might actually work on that, but let's see about that. Maybe someone else is quicker. We have some orange pie image already in OpenSus at Tumbleweed. They recently made a new model based on a very new SOC by the company called RDA. It's rather low-end Cortex A5 with I think only 256 megabytes of RAM. Unfortunately, as with many new SOCs, there is absolutely no support for it. And as is, we can't really do anything with it. However, earlier this year, an orange pie I96 was announced at Lenaro Connect, which is in the I96 boards, in this case IoT Edition Form Format. But it is not yet clear to me whether that will be a community-supported board or an actual in-hour reference board. So let's see how this software support turns out going forward. In a similar category, in Japan, there is a so-called FQ96 board by Fujitsu. There are huge patches available on top of older versions of Uboot and the kernel. However, there doesn't seem to be any work on making that supported in the mainline versions of kernel and Uboot. So we've been in talks to improve the situation there and let's see how that pans out going forward. Unfortunately, we did not manage to get one here in time for the conference. Moving on to 64-bit territory, the Raspberry Pi 3, which unfortunately we do not have here today. So unfortunately, we're not able to show anything with a display that's there, but we can show serial output later on after this talk. We did have Raspberry Pi images based on the 42.2 kernel. Mid of last year already by now it is available built in a factory with a factory kernel. There are some differences of note in particular. The factory image does not contain any support for Wi-Fi, whereas the 42.2 image has backports by Zuzer that do enable this. And thanks to Alexander Graf and Fabian Fogt in particular who have been doing a great job working on those images. An update on the Pi 64. So there had been community images for that in Contrib for quite some time already. By now it's actually possible to boot the Tumbleweed kernel if you're willing to sacrifice a bit of functionality. So in particular, network was not yet working. But if you have a USB to Ethernet adapter, then you can easily work around that. And be aware that there are some upcoming changes coming. So currently the Uboot package that we're building in factory only contains the actual Uboot binary and we're using some tools to actually make it boot with an all-winner firmware. Whereas the next version of Uboot that we don't have packaged yet will actually include a secondary program loader support so that basically we have an all open source solution for the Pi 64. However currently we do not have the untrusted firmware packages in Tumbleweed so we would be able to build a Uboot Pi 64 image package in factory. But that package would need to be rebuilt in the Contrib in order to actually provide the full booting support for that new booting approach. Based on the same SOC once again, there is a Nano Pi A64. There's no DTS for that yet. Should be relatively easy to add if someone has interest. In that particular one it's simply been a matter of time in finishing a lot of enablements for this conference. But that should be possible simply based on the software that is available for the Pi 64. Also leveraging much of the work that we had already done for the Pi 64, it's possible to boot the Orange Pi PC2 using the Pi 64 juice image simply by using a different boot loader. At this point in time we do not have packages for that yet but it was possible to build that by using the upstream Uboot sources and adding a couple patches on top. By now it might actually work using master branch of Uboot tree since this week I think. And again reusing the same chip and other board of that family. There is a patch available. The patch for Uboot works. Unfortunately I have not been able to test the juice image on there, not successfully tested. I'm assuming that's because the juice image is too large for 512 and we bought at this point in time. So if you have like an older Raspberry Pi you may want to double check that it actually still works for you. And please let us know on the mail list then or open a bug. Short update on the Geekbox. I have unofficial ATF packages building by now and there is the beginnings of an upstream Uboot port. This is not yet in the 2017 or 2005 version but should be in master branch at least soon. I think not yet. At this point only serial works so in theory you could use Minicom, PicoCom or some other tool like that in order to transfer kernel via the serial cable but that's really no fun so better wait and hopefully at some point we're going to have drivers for SD card. The successor to that particular SOC is the 3399. We've been able to boot Uboot on that board yet. However, the number of boot devices supported is not yet that big. EMMC was working for me. I also found a branch where network was working with some restrictions and I heard that I believe HICO has a branch where supposedly USB is working. So yes that is just being confirmed. Thank you very much for that. Hoping that will soon find its way into mainline as well. So last year once again I had talked about the Bubble Gum 96 and I believe I was asking whether anyone in the audience had access to one. That was not the case. One of our Chinese colleagues managed to get one, one such board to Germany and based on that I've been able to do some initial enablement for that. However, at this point still only booting into an in-it RD works but there's still no drivers for SD card or other devices. Again similar situation for the Andromeda box edge. I did some initial upstream patches for that. One can boot into an in-it RD with a minor MDT hack but no open zoosie yet for lack of drivers and in particular because I did not get the clock drivers to work yet. The so-called Armada 8040 community board has been rebranded Machiato bin since last year. It's still the same layout and hardware. We have a package, a Huboot package available for that. We've tested that one via chain loading but unfortunately the drivers in Huboot and the kernel do not match so basically I was able to install from SD card via a juice EFI image onto a Zata disk. However, obviously in that case the kernels get installed onto the Zata disk and then on next boot you can actually access the newly installed kernel so that's still rather hacky and let's hope that drivers make progress in Huboot for that to work. Or since last week or the week before there's instructions available for building EDK2 which at this point I haven't packaged yet. But the kernel did work for that board and like I said the generic EFI juice boots on that board can be used. Unfortunately for some of those boards not sticking to the SPSA specification it's necessary to switch the console from TTY AMA0 to TTY S0 or whatever it is for the particular hardware if it doesn't supply the path so that you can simply drop it. A similar chip from Arvel is being used on the Espresso bin. However unfortunately the driver situation in Huboot has been fluctuating so at some point Zata was actually working. It regressed in 2017 or five so I'm hoping that will improve going forward so that we can actually build images for that one. We also are showing an NXP based board where we have Huboot prepared for. Unfortunately there's no instructions on how to actually use that with so it would be necessary to load that by a network and train load it which is still to be tested. Does anyone here happen to have one? The Freedom board from NXP? Then very, very new there is finally software for the Poplar board. I did manage to get it working just days before the conference, pretty much the day before that. There are some initial packages for Huboot and L-loader available in a contrip. There's work. There's a patch available to a script in order to build a bootable partition table and partitions. However using Linux Next, EMMC is working. From that particular installation script you can actually boot into open Zoozer. I believe also SD is working in the kernel. However SD was not working in Huboot so using external images is still a bit tricky because Huboot supports USB but the kernel at least in my build did not support USB yet. At least it's looking much more positive than some months ago. Very new. We have the hardware here but no open Zoozer running on there yet is the high key 960. There are initial kernel patches available for that one yet. However the links to the EDK firmware I just received the other day so there was not enough time to prepare that but probably in some weeks or months we will have some initial image working on there hopefully. So now for the first half hour we've been talking about development boards and I now want to take some time to look at some other hardware as well. So what other devices are there that we might run open Zoozer on? So when the ARM port was still very early some people tried to use their ARM based phones, route their Android, run a change route in there with some open Zoozer packages in there simply to have some place to run things on. It's not something that I've been personally focusing on because phones and tablets often have the problem that you don't get serial access. I've tried to do that for the Nexus 9 ones but I never managed to get the serial to actually work limiting the things that you can then actually try with mainline kernels on there. But for instance we had open Zoozer running on the Samsung Chromebook, the initial ARM one, and I got it working on the HP Chromebook 11 as well for some time at least. Then more recently there are some do-it-yourself kits for building your own laptop so there are ones available based on the Raspberry Pi and there's also one available from, I forget the name, it's based on the A64 chip. And what's the company name? Only Max, yes, right, the ones with the all-inoxenor and so on, right. So there's kits like that available for building your own notebooks with a chip that you can then actually also debug in better ways than you can with consumer devices like Chromebooks mostly. Obviously for the record there are servers that are running ARM and we did see the presentation of the, from Softiron at the keynote last Open Zoozer conference, those devices are available but well they're not exactly available for small budgets at this point yet. So they do exist and we have Open Zoozer running on multiple of them but we've usually not been covering them because it's not what most people here in the audience are actually going to have access to. And then to the final part, routers and AS devices and TV boxes are available from lots of vendors in some cases with device trees and mainline kernel support already available and in other cases it's possible to do that in fairly easy ways. And playing with those, failure is always possibility. So like I said, doing my own electrical circuit for making the headphone output switch to a serial output on the Nexus 9 didn't quite work so I pretty much gave up those efforts. I had also worked on a MediaTek based Xiaomi box, TV box that is. I did not manage to locate the serial pins to get any output from there. And then there was a Kickstarter project called the Row Board but unfortunately unlike the initial plans it was actually chipped in a way that no one can actually really tinker with it so there is no bootloader access to those at all. There should be some JTEC pins if one locates them and actually wires them up and writes the necessary drivers to do something with that. But at this point it's not possible to run them, to run open-suzon on that board. If you try some of those consumer devices that are not yet documented to work, obviously chances are that people can't tell you what you need to do if you see this error or if you don't get output at all. So basically use external media, don't overwrite the EMMC, think about what you're going to do when the kernel gets stuck or you overwrite something by accident and maybe your partition is gone. Do backups if you can, like do a DD from an Android that is shipping on the device, back it up to another device. That's a fairly safe way. In some cases there are USB based backup solutions. We've been packaging a few tools to help with that. So there's the Sanji tools available and I've prepared and need to resubmit the RK develop tool for Rockchip. So you may find information what to do for certain types of devices in general but usually not specific to those devices. And in particular where the vendor is located it might become difficult to sue them to actually give you all the GPL sources and instructions on how to actually make something bootable out of those sources for a particular device. Now already last year I got my hands on this particular TV box, the Vega S95. It was one of the first devices with two gigabytes running at that point in time, AMlogic S905 M-chip. It was the first 64-bit chip from that particular vendor and in the meantime I've managed to get a chain loaded mainline U-boot to work on there. So basically I'm loading U-boot via the network and then jumping into the new U-boot so that we actually have UEFI support in there. And by now there is also since the 2017 or five version there is MMC support so it's possible to load things from an SD card. Tumbleweed kernel is working on there out of the box and just be careful that because it works on this particular board or box device does not mean that it may work on another device that you have access to that may require some tweaks. Maybe the firmware is more restrictive, does not give you a prompt to enter the necessary boot commands so it may require some more tinkering based on what exactly you want to do also. On the next slide I'll go a bit more into how the firmware is structured in this case. So the reason that I've got chain loading in this case is that I have not yet successfully tested the tools to make a firmware image out of U-boot that can actually be flashed onto EMMC or another bootable device there. Again when thinking about recovery strategies one such strategy might be if the device is capable of booting on SD card either than doing such experiments on an SD card but unfortunately in most cases like here the EMMC comes before SD in the enumeration order so basically one would need to back up the EMMC probably and then do experiments on SD or directly on EMMC. The good news is that besides those TV boxes there's also development boards available that have better access to pins and more documentation available. So by now there is a juice image available for the OdoiC2. It works out of the box and in order to get to this point I had to hack together some tools that are packaged as MISON tools. MISON is the code name for this family of system on chips. Actually the U-boot bootloader is combined with some ATF like firmware blobs and amended by certain headers that have description about offset sizes and check sums. And there was a proprietary tool available from Amlogic for x86 machines. You can find that in various GitHub repositories. However we are building our AR64 images inside OBS on AR64 hardware so we can't really execute x86 binaries even if we were allowed to use x86 binaries without sources to build our packages in there. So what I did was write a new tool called AMLbootsig which basically was created by comparing binary output of input and output files used with the original tool and then starting to write the tool in such a way that it generates the same output or at least similar output by now as the original proprietary tool and this is working for this particular board. If you have other boards I am very happy about any feedback on whether this board works simply because there is no documentation available for this format and much of this has been guesswork including the names of struct field and what they actually mean and are supposed to contain. Based on the same chip there is another development board available since recently the Nanopi K2. I've sent tru.l patches to get it booting and it is working however there is no contra image for that yet because on the one hand we don't have a Uboot package yet. The firmware blobs are not yet packaged and my tools are working with that but there simply is no fully booting juice image yet but basically I keep saying that you need to combine a self built boot loader with the juice image in order to get it to boot. S905X is a distinct chip from S905 at this point in time there is only downstream Uboot support so it is not in mainline. I have not yet tested our kernel on there. I do know that the Maison tools do not support this particular chip yet so that will require some more trial testing and because of all that obviously there is no juice image for that available yet. Someone on the mailing list was reporting that he simply took another Linux image and simply used our juice root of S-Tarball that is obviously an option for many of such cases but obviously we want to have a proper solution that we can give to our users in LBS. At Fostom I had shown a TV box running the S90912 chip. Uboot for that is not yet available mainline. I have submitted patches to make the mainline kernel boot on there that was what I was showing at Fostom not here today sadly and the boot image tool does not support the S9012 either at this point in time. Now something that I am very proud of having accomplished is I got my hands on a TV box with a very new Realtek 64 bit sock. There are unfortunately absolutely no sources available neither for the boot loader nor for the kernel but after a long time of having no success with this I found a way to actually boot a U image on there and by now it is possible to boot into an INIT RD. Since yesterday the patches for that are also integrated into the Linux next tree and hopefully will make it either into 4.12 or 4.13. In addition to some of the Rockchip development boards already mentioned earlier there are also TV boxes. I know that Matthias Brogge has worked on a TV box at some point with the RK3368. Did you have success with that yet? Not fully. Okay. I did not have success here yet either but I wanted to mention this for completeness because at this point in time we are starting to see the first devices, the first consumer devices ship with a U-boot that is new enough to actually contain Alex Graf's UEFI support. So this has a modified version of 2017.01 on there and it is possible to reboot into the Rock USB mode and connect to the board with the RK develop tool that is upcoming for factory. However I have not yet managed to actually get into the mask row mode that would be necessary to flash an updated or modified version of U-boot on there. Heiko, have you been able to play with any such devices or boards yet? But I am pretty sure RockTrip is actively working on this and something should be available in the upcoming U-boot version and then the question is how much changes might actually be necessary to make it work on not their internal reference boards but the devices that we actually have access to as mermodels. Last but not least, last year we had the Taurus Omnia in the room and that is a Wi-Fi router that was launched on Indiegogo and Michal here in the room is working for the company that did it. By now I have open zoos of booting on there. With me and someone else worked on upstream patches, it is available in the kernel yet. Already however the U-boot that it was shipping did not have support for our init RD and since a couple of days, possibly weeks there are patches for mainline available where we are still waiting for a second revision and then hopefully we should start to be able to boot open zoos on there without major hacks. So far for the first part of this talk. Now if we are looking beyond just getting the hardware to boot our operating system and having sufficient drivers in there, many of those development boards at least have connectors where you can actually attach sensors, motors and various other devices and buses. If we look at the Raspberry Pi for instance, then it has this originally 26 pin now 40 pin connector with various functions available and the way that it works in Raspbian is that there is a number of DTBO files delivered on the boot partition and you can configure either manually via the config text or via a tool that they are shipping to have those DTBO files applied as overlays to the base device tree. Whereas in the case of mainline kernels and open zoos we do not have any DTBO files yet. I have started preparing some for the expansion boards and in some cases external sensors or devices that I had accessible but this is not yet sorted out how this will actually move forward. Obviously there are questions of how can we actually possibly reuse snippets for such device trees that on the one hand need to connect to a board specific device tree but where basically the functions that each expansion board is providing are always the same. So this is not yet really solved at this point in time yet and the solution that I have been testing on open zoos is to simply write a boot script for Uboot that after Uboot has loaded the device tree, the base device tree, it applies a hard coded set of trees that happen to match my hardware and afterwards the kernel can simply reuse all the devices in the tree. If we look further into the future then the idea is that also the kernel should be able to apply some of those device tree overlays at least when you don't need it to load something from inside Uboot which is a whole other topic. It also really depends on live device tree in Uboot. But for the standard cases the idea is that you would actually install into the Linux file system a set of DTBO files and you would configure them to be applied in some way possibly via a system D demon or simply by self written unit file. Maybe long term it would be even an idea to have a YAST module to configure such well GPIOs and expansion boards but as long as we don't know how exactly the underlying tools will look like we haven't really ventured into that territory yet. So I'm going to show two projects that I've been working from just as examples of what is possible. So I had access to a very small microcontroller kit that had a detachable I2C connected sensor on it. There was no mainline kernel driver available for this particular chipset and obviously if you need to write an overlay file yourself the first thing to find out is what you actually need to write into there to make it work. On the next slide I will show a bit about generic drivers. Here is an I2C dev driver where you can generically access I2C devices from user space. However, what I was looking into was a real kernel driver for this and it's actually pretty easy to write once you actually have the data sheet available which for those ones here is available. So basically I just need to add the finishing touches and get that into mainline kernel and that is something that anyone having such boards really should look into. It's easy to do in some cases and is simply the most reliable way to use certain boards in the driver. You will find lots of instructions in the web that will tell you to download particular libraries but a lot of them have licensing and also functional problems when using them with the mainline kernel and depending on what software you actually have to then combine it with. There are more standard drivers in the same category. The next one I'm still working on. In theory it should be possible to use for example TPM chips from Infineon with the mainline kernel. The current generation is spy based. The previous one was I2C based. Unfortunately the spy based ones don't really get recognized although in this case there are mainline drivers available already. I'm not sure yet and hope that we can sort that out with them together. There's a number of Arduino shields available and in case you're not yet aware I've started documenting in the wiki based on suggestions from Michael. There are various adapters available that you can actually use for example a Raspberry Pi board with the 40 pin connector. From there go to an Arduino connector and then you basically can use almost the whole range of Arduino boards that are available out there as long as the voltage levels are compatible and as long as the board that you're using it with has the right functions available on the pins. So for example there are boards available that do not have spy implemented in hardware so you would need to either use a bitbanging on the GPIO pins or simply use another board that actually has those functions available where a particular hardware design expects it. The second project to showcase that I would have loved to talk about more but unfortunately is very slow going so in case you don't know what Lora is this is a wireless technology for low powerless wide area networks so you can go for maybe three kilometers have a signal transmitted by using a certain signal spectrum and there is among others a protocol available called Lora 1 which unlike some other protocols like for example ZikFox and the new NB IoT is actually available so that you can run your own gateways. So basically you can have end to end communication via this technology in theory all running on open Zuzer. There are some various GitHub projects to do this in user space however every time you try to use the spy dev driver on mainline kernels you get a huge one on stack trace that you're not supposed to do this. We had some conversations about this at FOSSTEM with some of the spy maintainers and they do not intend to change this because they're saying that's not the right way to use spy devices unless that particular use case has been vetted to be absolutely necessary and their recommended workaround I wouldn't call it solution was to reuse the device tree compatible from one of those white listed devices instead of the one instead of the literal spy dev name in order to get around that but that's not really a clean solution and as already mentioned a number of in particular one very widespreadly used GPIO library for the Raspberry Pi is under LGPL30 and later whereas most of the software that people are trying to use with this is under GPL2 which we cannot legally package in OBS unfortunately. So basically the software for user space is not in a very great shape. There's no kernel drivers so I was asking about this at a Lora talk at FOSSTEM apparently no one at that point in time had been working on kernel drivers for those particular chipsets so I started to do that on my own once again. I'm not really a networking expert on that socket layer in the Linux kernel so things have been a bit rough for me but I do have modules available in this particular GitHub repository that can be compiled against an installed open-to-user kernel. It's doing some weird hacks like reusing socket identifiers in order to not go beyond the list of defined protocols so some care must be taken to not run into weird errors but it's possible to test such things. Also on the previous slide the sensor driver that I developed I did that as a local kernel module in the running open-to-user system so I'm very much encouraging people that if they have a working open-to-user kernel they can actually use that for development of additional drivers or back ports of additional drivers on top of that as in particular a KMP if you do it in OBS or if you do it locally you can just build the KMP and forcefully insert it. It will show an ugly tamed warning but it works. After having the spy driver prepared I also set out to write the first ZERDEV based driver so this is new in 4.11. It's a way that you can actually enslave a kernel driver to a serial port. So usually you would get if you have a serial port enabled in your device tree you would get some TTY whatever device inside the kernel and then you can use user space tools to read and write from that device. In this case you can have a kernel driver implementing serial based protocols. There's initial drivers being prepared for some Bluetooth chipsets that was the main driver on various boards so on the Raspberry Pi 3 42.2 image it's necessary to call HCI Attach in order to load the firmware onto the actual Bluetooth module, the Wi-Fi and Bluetooth module for Bluetooth to work and the idea is to have all this handled by the kernel. Similarly, the Pine 64 has a Z-Wave module available for home range wireless communication. In theory it should be possible to write kernel drivers for all those technologies wherever it makes sense to abstract a generic interface so that user space no longer needs to know which hardware exactly it is actually dealing with. Approaching the end of the talk, cross compilers have been an issue occasionally coming up. Obviously you can build ARM software inside OBS running on ARM hardware for 32-bit and 64-bit. With ARM V6 I would get to say that we're currently having for some packages some emulation problems ever since the G-LiP-C introduced some optimizations so you may see some weird assertions on ARM V6 but ARM V7 and ARM V8 should work well enough. However, if you're building a kernel maybe you just want to cross-compilate from your X86 based notebook. So there are these cross compilers available just for reference. They're only suitable for the kernel, the 32-bit version can also be used for UBUT when using a UBUT internal libGCC copy. I have prepared in the last days a newly-based ARM cross compiler. This should work for any firmware development for Cortex-M devices. I'm not yet sure how far it works for Cortex-A. If anyone is interested in that please give it a go. The next step would be to prepare a cross compiler like this for AR64 so that again we can also have our open-zoos cross compiler available in order to build UBUT for AR64 by a cross. So that is it for this talk. We still have some minutes left for your questions. I know I've talked a lot. Don't be shy. It works, yes. Yeah, you might not know it but in front of you there's a nice Zdo box with your Starming and M-Star MSO chip 9180 down there on the ground which is capturing the HDMI signal and giving it back scale to the beamer and to our input source for recording. At the moment it's running some Android with some Nasty vendor app which is recording the HDMI and giving it out to the output. I would like to see it next year on Lightning on Tumbleweed of course. I think we all agree that that would be nice to have. However, this is not really a wish concert. You can express your wishes but it will need someone to actually work on it. It was difficult to get all the hardware that I've worked on here for this event this year and of course you can assume that it takes quite some time. I'm trying to navigate back to a thing that was on the failure slide. So I did not quite catch the exact number but it sounds like a similar chip as on the row board so I would not be too hopeful. So the thing is that I have actually talked to a representative from M-Star about it and that person said that there is nothing inherently blocking other people from booting something from via their boot loader such as us as a Linux distribution. However that depends on the boot loader configuration from the particular vendor. So basically it's on a case by case basis and in addition to that there are no kernel drivers upstream for that so you'd need to get access to the sources for the device and they use their own, I think it's called M-Boot boot loader which is not related to UU boot so I'm not sure whether sources for that one are available and how well it's documented what exactly to do with that. However, if you use Google you will find slides from I think the Narrow Connect 2016 where their director of 96 boards was mentioning an upcoming M-Star based 96 board which I think would even have a 64 bit socket on there but obviously that would not help with a particular device that you have access to the question would rather be would any of all these devices be realistic to get into a state where they're doing video input and output processing in the way that you need them for this particular use case? Exactly because I mean it's probably not really interesting to have Tumbleweed running on the Tumbleweed kernel running and having a serial output and network device but what you want is the HDMI input, HDMI output and HDMI capture and hell will freeze over before you get this without closed source render drivers. I mean I have all those TV boxes that you mentioned are probably all IPTV boxes, correct? They don't have any tuners. Some do, some don't. Okay because I mean I'm working for about almost 15 years now with satellite setup boxes and you never ever the only thing where you get an open source driver is the old D-Box 2 which was simply hacked and so and which was actually hacked with with help from the hardware vendor as is known today. So all those multimedia boxes are probably hardly worse spending lots of time because I mean it's fun for for education to have the kernel booting but you often cannot do really much interesting things with it because you will never be able to get or never. It's unlikely that you will get video in or out there apart the only one where this really works out of Raspberry Pi is because they have the rather open drivers. That's that's my. And even there the driver situation is progressing very slowly at this point. Yeah but at least you have to have access to the encoder and the decoder and stuff and so you can you can actually use this. So but it's really interesting and I think I forgot to mention that after I did the the initial patch set for for the S905, Bay Libre was contracted to do mainline enablement for for the amlogic chips that are being used in many of those Chinese TV boxes. And in the photo 12 kernel, HDMI should be working as output. And I believe there's also some work on on video encoding, I thought, but I'm not entirely sure. So it really it will depend on the particular vendor. So we've been in contact with Rockchip and there are like G streamer packages and other open source bits available. Some vendors are trying real hard to to be a good open source citizen. But if you buy the box, that's not the state that they will actually ship at this point. And well, it's your right that it will take time and effort to be surprised in a positive way because I'm actually looking for people asking me for quite some years. What's an open source TV box to buy? And I say, yeah, there is none, basically. I mean, there are all those all those. I'm usually hacking on satellite TV set of boxes. And there are different different states of closed, but they all have closed source drivers and they're all crap, basically. So it's it's just a selection of crap that you can get. So I would like to be positively surprised, but I won't hold my breath for it. So you do have a point there and I have to maybe point out that when I'm working on some of those TV boxes, I'm not working on the TV boxes in order to get video encoding or TV streaming working, but rather I'm using that as a means to get early access to some of the chips as long as no development boards are available. So yes, my use case is not really getting to to that full-fledged system, but I found that if you actually document and make initial patches available so that people can have a semi-working system, then more people are likely to contribute to that port than if you're just sitting for a box where you're not getting where you're having a black screen on HDMI and you're not getting anything sensible coming out of the serial system. So it depends on how large the community is and obviously there's a much larger Sunshee community than for some of those others more odd vendors that I've mentioned here. And well, yes, it depends on individuals to contribute drivers to make things work and it's questionable whether we will ever get to 100%. So one thing that I omitted from this talk simply because there's been no real progress is Mali. So there's often confusion in that if you actually want to have graphic output on a board via HDMI connector or whatever the board offers, you don't need to have Mali drivers. Mali drivers are only for 3D acceleration. They're not currently mainline available. There are GPL drivers available and I even have some of them packaged in Contrip Mali. However, they keep breaking whenever the kernel gets updated and it will require a lot of documentation and tinkering how to find out which version of the driver to combine with which device tree overlay and which binary user space download from whatever external source in order to possibly make that work. Have you looked into the Halium project? Halium project is like what we eat. Like in honeycomb. Halium. H-A-L-L-I-U-M. So the project that Plasma phone and UB ports people started so that these devices, these platforms can run on different devices. Okay, well, maybe you can take a look at it. It could make your life easy somehow, somewhat, and being friends with them could be useful for you, maybe. In which way could you describe that? Okay, well, I'm not speaking for the project, right? But the idea is that you know only Pibris, for example. So when you try to port Linux system into mostly phone devices and tablets, you have the problem that you get the driver for Android, but you don't get for anything else. And while you've been mostly talking about how getting output from HDMI is success, well, in practice it's not really success unless you just want to show like a static thing, right? As long as you want to have humans interacting with it and a touchscreen, you want to have accelerated graphics. So what Yola started doing was using Android graphics drivers. So basically you're saying that the software project is making Linux compatible user space parts available to use an Android kernel with an open-to-the-file system plus those additions? So the thing is that Pibris, for example, was there for a while, but it was only available for some devices. What they're trying to do is to kind of get a pull-off devices, mostly phones and tablets, that are supported. Like if I told you today, port Plasma phone to my device, you would tell me, well, I don't really know where to start from, right? And well, there's going to be these kind of projects that will have Halim configurations and kernel configurations so that you can get device to boot and this kind of stuff. But anyways, if you think it's interesting, tell me later and I will get you in touch with the people who actually know about the project and maybe you can be friends. I don't know. Thank you for bringing it up. And I assume it may be interesting to some people in the audience or viewing the recording. To me, personally, obviously the goal is to have open-zoos are working and that in the end requires to have at some point the open-zoos are kernel working where I understand that would then not no longer be necessary. For the questions? So you've highlighted a vast range of hardware, et cetera, and a lot of it doesn't appear to have upstream support, whether it be in the kernel or U-boot. Do you feel that ARM vendors are getting better at upstreaming or is the situation still the same where the upstreaming of platforms is still really bad? And be honest. I'm trying to think about the numbers in my head right now, but if you go through my slides afterwards, I think you will find quite a disappointingly high number of new boards where vendors are still sticking to the old fire and forget BSP model where they do like a U-boot port once based on whatever old version is. In the end, I think it's like a trickle-down model that is still being used in many cases. So a particular chip vendor makes a U-boot port, he passes that on to the board manufacturer, they maybe do a few or three changes, but no major rebases like that, and that then gets shipped and then it doesn't see any updates. I have seen, for example, well, NXP for a very long time has been active in both the U-boot community and the kernel community. Marvell is also very active in those spaces, well, at least Marvell Embedded Business Unit, and there is a number of other vendors that are also doing great code, in particular on the kernel. Obviously, there are some commercial like server vendors that don't need to do any U-boot work because they're using like AMI commercial firmware, that simply works. But I still feel that despite a lot of talks on this topic and lobbying, not all companies in particular, when they're like new to Linux and only doing Android, haven't really learned the lesson yet. And if you see any ways how Arn, Linaro, or any other organization, maybe the Linux Foundation or Free Software, whatever can help with that, that would be absolutely awesome. On the other hand, I have seen individual companies getting more involved with open source, so there are certainly encouraging developments within the market. Like for example, RockTrip is getting more and more active with their new 64-bit models or in other cases, companies are simply seeing in need either being driven by enterprise distributions or for whatever reasons to contract other people to do that upstreaming work for them and still doing like to some degree parallel initial in-house development that will never go upstream and then have something that will go upstream, but in the end, there's still both parts of it. So things that are, have been improving and things that are still bad. Hello. Have you heard of the Geekbox? It's a set-up box with an arcade 30... You have? Yes. Oh, okay. I worked on the U-Boot port for that one. At this point in time, unfortunately, there is only serial output working. There's a bit more drivers contributed by RockTrip by now, but last time I tested it before the conference, it was not yet ready to really boot open the user. But what I have done on there is I flashed an Android-style, self-built kernel image using the upstream kernel onto the boot partition and used that with an open-zoom-zeroot-faz file system. So it's possible to run open-zoom on there if you're willing to get your hands dirty. Okay. So, and the next thing is I've got a Remix Mini. If you want, you can take a look at it later on. Thank you very much. Any further questions? And thank you very much for your attention. I hope that there was something for your hardware in this talk. If not, come and talk to us about whether it's possible to get it supported or how likely something is to get done. And there is the open-zoom-z-arm mailing list to ask questions or follow things that are happening. I admit that I don't usually spam people there with all the stuff that I'm doing, but you can see the category arm devices on the open-zoom-z-wiki where most boards that have been enabled have at least some stoppage that you can see someone has already been looking into it. If not, if you have some device and it's working, please document it in the wiki and, yeah, contributions are always very welcome. This is not a one-man show. So thank you for your support in doing this, also in providing test feedback as new kernels get updated or new images come out. And thank you again.
 So, hello.  My name is Andreas Verba and I will be giving a status update on what's been happening with  the OpenSuser ARM port in particular in terms of hardware support.  Let's start with a small disclaimer.  So, I will be talking about hardware in this talk, but this is not supposed to be a guide  for actually buying hardware.  I will not be going into much details of the hardware, but rather into the state of what  the software is looking like and where currently things are working and where things are not  yet working so well.  Initially, I will be going through the various number of boards grouped by the architecture  that they are using.  Afterwards, you can kind of think of this as covering two dimensions.  So, on the one hand, they keep new boards keep coming up and new boards keep getting  enabled for OpenSuser as well then, but on the other hand, there is not just drivers getting  added for boards, but obviously, there's things that you may actually want to do with a board  once you have it booting.  So, you may want to connect additional pieces of hardware for it and I will go briefly into  that topic at the end as well as covering some work for actually building software for  ARM.  Additionally, on your right-hand side, stage left, you will see a number of boards that  I will be talking about later on here.  So, feel free to walk there either during the talk or after the talk and let's get started  now.  One key piece that we always need when we are dealing with ARM boards is information.  That's something that in some cases is lacking in some other cases where more people are  using it is more widely available.  So basically, you need to know what you need to put on a particular medium to actually  make the hardware boot.  You don't have a bias usually on there, not in a UEFI firmware either on most non-server  boards for the community.  So you may need to actually do something to get it to show something on the screen or  on the serial cable.  And if you do not have such an advanced server firmware that provides ECPI tables even, then  you also need a so-called device tree.  Next question then is, does the Linux kernel, in particular the OpenZoozer kernel already  contain drivers for the various peripherals of the chip that is located on your board  and not just for the system on chip itself but also for power supply and various other  possibly board specific parts?  It may be possible that a generic juice image or DVD image can actually boot if the board  has UEFI.  If that is the case, then you're all set.  However, if not, and this is going to be the majority of the cases I'm going to cover  next, then you're going to need an image that is tailored to that particular board.  When preparing an image for a board that no one else before you has enabled, then you  will have to take care of two stages.  So in particular, you have to make sure that the initial in-it RD contains all the driver  modules that are needed for the board to come up to the actual Routefes.  If you have the installation in DVD, basically that step is not relevant.  However, you still need to make sure that also in the second step, then the in-it RD  that is generated from within the running system also contains again all those modules  to boot for the second time again.  So basically that may require doing some tweaks for drag-with-config.  As I already mentioned, not so many boards by numbers that are out there actually contain  the UEFI firmware on some flash chip on the board.  If that is not the case, then you need such a just enough operating system image, for  example, to get started or some customized image with an additional software that you  actually want to run there as an appliance.  However, we have found that this does not scale very well, so basically on the one hand,  it takes time to find out how do we actually boot on a particular board.  Then all the necessary packages need to be accepted into factory.  If that needs to build, building that also takes time and resources, and the number of  onboard keeps growing.  In previous talks at last year's Open Thusa conference here at this stage and at various  other events, Alexander Graf has been presenting work for making the UBoot bootloader implement  the UEFI specification to some degree.  The idea with that is that going forward now, we actually want to move towards generic installation  images or generic juice images rather than board specific images.  The idea here is that we would like to split the firmware parts from the operating system  parts on the other hand.  That then leaves the question where would users actually then get the non-generic pieces  of the firmware to actually boot to such a point.  For that, obviously, OBS seems like a really nice fit where we're already doing this to  some degree.  However, we're still seeing some issues that Kiwi simply assumes that you have a relatively  standard Linux configuration and that you have a boot partition or a root of S partition  on there with lots of files being populated from packages, which would actually not be  necessary for a pure firmware image.  That is basically where we're currently headed as a prerequisite to what you're going to  hear next.  Let's start with the oldest generation, ARMv6.  We already had the Raspberry Pi 1 model B working with Tumbleweed last year.  What's been new is that the Raspberry Pi Zero is no longer a theory that no one can actually  purchase, but it's actually possible to get your hands on one by now, at least in some  regions of the world.  Basically, the same Huboot package that we're using on the Raspberry Pi 1 is also working  for the Raspberry Pi Zero, as well as the kernel and the juice image can simply be reused  and are actually working, including the UEFI support.  Even newer now is the ZeroW, which has an additional wireless chip on there.  Unfortunately, this is not working at all.  Basically, you don't even get serial output from Huboot.  At this point, there is neither a DTS file available nor any work on that device yet.  Does anyone here in the audience happen to have one?  Okay.  A few hands.  If you find anything out about that, make sure to let us know.  But at this point, unfortunately, OpenSUSE is not yet running on there.  Moving on to ARMv7 then.  In particular here, I'm very proud to present that we have another contribution by a community  member, Frank Kunz.  He had this DE0 NanoSock board with a Cyclone 5 SOC, and he's packaged Huboot to run on  there, and UEFI just happened to work on there out of the box.  I believe he's using the kernel default because, obviously, kernel LPE wouldn't work.  There is a factory image with the name here that you'll just have to read for yourself.  Basically, this is all working in OpenSUSE at humbleweed by now.  Thank you very much.  And an update on the Firefly RK3288.  There has been a bit of fluctuation on which Huboot versions actually boot on it.  The current version in factory 2017.05 is working again.  I did have the kernel LPE image booting on there, but unfortunately, we haven't been  able to get the juice image working.  It simply, I think, it gets stuck during early code already.  Similarly, oh, no, sorry, I mixed those up.  So basically, the Firefly gets to a point where devices actually are starting to get  enumerated and loaded on serial.  So basically, there's probably some modules missing in the INEAD RD.  Then a few people have been asking about the Tinko board.  This is a board using the very same chip, but in a Raspberry Pi form factor by ASUS.  And we do have Huboot working on there, but unfortunately, in this case, the juice image  is stuck in early con because this uses a different power management IC.  So basically, either some modules are still missing in there, or we may need to change  some modules to build in for there.  Does anyone in the audience here today happen to have one?  Okay.  Then some users had asked for the Mewdo Neo board.  There is a Huboot package for that now.  I also prepared a juice image, but it is getting beyond the INEAD RD.  However, it hangs at some point, I think, after Etnavive is initialized.  So either it's an issue between the various models of the Eudonio basic board or some  pinmuxing or some other setting in the device tree might be wrong.  Then an update on the guitar module.  Last time I reported that basically nothing was mainline and openZoozer was not running  on there.  This is still the case at this point.  However, I sat down and started writing patches in order to boot a mainline kernel on there,  and at this point it's possible to boot into an INEAD RD, but not yet further because drivers  for SD card and other devices like USB are still missing.  The Nenopinio is one of several Sanji devices based on the H3 SOC.  We have a package in factory since recently, but now that is actually booting.  Unfortunately, as for most of all Windows devices, UEFI support is not yet working inside UBoot.  So if anyone has such devices, I'm pretty sure there will be someone listening to this  talk.  We need people that actually sit down and debug why that is, adding some debug statements  to UBoot and possibly adding some memory reservations to make that work.  We have an image available.  It boots everything, worked out of the box surprisingly for once.  That was a really nice experience.  However, some users actually wanted not the Neo, but the Neo Air to work, and that is  still not working.  So we have an Nenopinio Air package by now.  However, the kernel does not have the device tree.  So the question is, does the device tree that is contained in UBoot is sufficient for that?  And unfortunately, I did not yet get feedback from the community on whether that is the  case.  So if you have such a board, please let us know.  If you tell us that it actually works, then we can enable that and choose image in Tumbleweed.  Another board of that same family, which by the way you can all see over there on the  tables, is the M1 plus.  Based on the M1 design, as far as I understand, and adds Wi-Fi on top of that.  There were some patches for the M1 model, but no work for the M1 plus at this point yet.  So if we get time, we might actually work on that, but let's see about that.  Maybe someone else is quicker.  We have some orange pie image already in OpenSus at Tumbleweed.  They recently made a new model based on a very new SOC by the company called RDA.  It's rather low-end Cortex A5 with I think only 256 megabytes of RAM.  Unfortunately, as with many new SOCs, there is absolutely no support for it.  And as is, we can't really do anything with it.  However, earlier this year, an orange pie I96 was announced at Lenaro Connect, which  is in the I96 boards, in this case IoT Edition Form Format.  But it is not yet clear to me whether that will be a community-supported board or an  actual in-hour reference board.  So let's see how this software support turns out going forward.  In a similar category, in Japan, there is a so-called FQ96 board by Fujitsu.  There are huge patches available on top of older versions of Uboot and the kernel.  However, there doesn't seem to be any work on making that supported in the mainline versions  of kernel and Uboot.  So we've been in talks to improve the situation there and let's see how that pans out going  forward.  Unfortunately, we did not manage to get one here in time for the conference.  Moving on to 64-bit territory, the Raspberry Pi 3, which unfortunately we do not have here  today.  So unfortunately, we're not able to show anything with a display that's there, but we can show  serial output later on after this talk.  We did have Raspberry Pi images based on the 42.2 kernel.  Mid of last year already by now it is available built in a factory with a factory kernel.  There are some differences of note in particular.  The factory image does not contain any support for Wi-Fi, whereas the 42.2 image has backports  by Zuzer that do enable this.  And thanks to Alexander Graf and Fabian Fogt in particular who have been doing a great  job working on those images.  An update on the Pi 64.  So there had been community images for that in Contrib for quite some time already.  By now it's actually possible to boot the Tumbleweed kernel if you're willing to sacrifice  a bit of functionality.  So in particular, network was not yet working.  But if you have a USB to Ethernet adapter, then you can easily work around that.  And be aware that there are some upcoming changes coming.  So currently the Uboot package that we're building in factory only contains the actual  Uboot binary and we're using some tools to actually make it boot with an all-winner firmware.  Whereas the next version of Uboot that we don't have packaged yet will actually include  a secondary program loader support so that basically we have an all open source solution  for the Pi 64.  However currently we do not have the untrusted firmware packages in Tumbleweed so we would  be able to build a Uboot Pi 64 image package in factory.  But that package would need to be rebuilt in the Contrib in order to actually provide  the full booting support for that new booting approach.  Based on the same SOC once again, there is a Nano Pi A64.  There's no DTS for that yet.  Should be relatively easy to add if someone has interest.  In that particular one it's simply been a matter of time in finishing a lot of enablements  for this conference.  But that should be possible simply based on the software that is available for the Pi  64.  Also leveraging much of the work that we had already done for the Pi 64, it's possible  to boot the Orange Pi PC2 using the Pi 64 juice image simply by using a different boot  loader.  At this point in time we do not have packages for that yet but it was possible to build  that by using the upstream Uboot sources and adding a couple patches on top.  By now it might actually work using master branch of Uboot tree since this week I think.  And again reusing the same chip and other board of that family.  There is a patch available.  The patch for Uboot works.  Unfortunately I have not been able to test the juice image on there, not successfully  tested.  I'm assuming that's because the juice image is too large for 512 and we bought at this  point in time.  So if you have like an older Raspberry Pi you may want to double check that it actually  still works for you.  And please let us know on the mail list then or open a bug.  Short update on the Geekbox.  I have unofficial ATF packages building by now and there is the beginnings of an upstream  Uboot port.  This is not yet in the 2017 or 2005 version but should be in master branch at least soon.  I think not yet.  At this point only serial works so in theory you could use Minicom, PicoCom or some other  tool like that in order to transfer kernel via the serial cable but that's really no  fun so better wait and hopefully at some point we're going to have drivers for SD card.  The successor to that particular SOC is the 3399.  We've been able to boot Uboot on that board yet.  However, the number of boot devices supported is not yet that big.  EMMC was working for me.  I also found a branch where network was working with some restrictions and I heard that I believe  HICO has a branch where supposedly USB is working.  So yes that is just being confirmed.  Thank you very much for that.  Hoping that will soon find its way into mainline as well.  So last year once again I had talked about the Bubble Gum 96 and I believe I was asking  whether anyone in the audience had access to one.  That was not the case.  One of our Chinese colleagues managed to get one, one such board to Germany and based on  that I've been able to do some initial enablement for that.  However, at this point still only booting into an in-it RD works but there's still no  drivers for SD card or other devices.  Again similar situation for the Andromeda box edge.  I did some initial upstream patches for that.  One can boot into an in-it RD with a minor MDT hack but no open zoosie yet for lack of  drivers and in particular because I did not get the clock drivers to work yet.  The so-called Armada 8040 community board has been rebranded Machiato bin since last  year.  It's still the same layout and hardware.  We have a package, a Huboot package available for that.  We've tested that one via chain loading but unfortunately the drivers in Huboot and the  kernel do not match so basically I was able to install from SD card via a juice EFI image  onto a Zata disk.  However, obviously in that case the kernels get installed onto the Zata disk and then  on next boot you can actually access the newly installed kernel so that's still rather hacky  and let's hope that drivers make progress in Huboot for that to work.  Or since last week or the week before there's instructions available for building EDK2 which  at this point I haven't packaged yet.  But the kernel did work for that board and like I said the generic EFI juice boots on  that board can be used.  Unfortunately for some of those boards not sticking to the SPSA specification it's necessary  to switch the console from TTY AMA0 to TTY S0 or whatever it is for the particular hardware  if it doesn't supply the path so that you can simply drop it.  A similar chip from Arvel is being used on the Espresso bin.  However unfortunately the driver situation in Huboot has been fluctuating so at some  point Zata was actually working.  It regressed in 2017 or five so I'm hoping that will improve going forward so that we  can actually build images for that one.  We also are showing an NXP based board where we have Huboot prepared for.  Unfortunately there's no instructions on how to actually use that with so it would be necessary  to load that by a network and train load it which is still to be tested.  Does anyone here happen to have one?  The Freedom board from NXP?  Then very, very new there is finally software for the Poplar board.  I did manage to get it working just days before the conference, pretty much the day before  that.  There are some initial packages for Huboot and L-loader available in a contrip.  There's work.  There's a patch available to a script in order to build a bootable partition table and partitions.  However using Linux Next, EMMC is working.  From that particular installation script you can actually boot into open Zoozer.  I believe also SD is working in the kernel.  However SD was not working in Huboot so using external images is still a bit tricky because  Huboot supports USB but the kernel at least in my build did not support USB yet.  At least it's looking much more positive than some months ago.  Very new.  We have the hardware here but no open Zoozer running on there yet is the high key 960.  There are initial kernel patches available for that one yet.  However the links to the EDK firmware I just received the other day so there was not enough  time to prepare that but probably in some weeks or months we will have some initial  image working on there hopefully.  So now for the first half hour we've been talking about development boards and I now  want to take some time to look at some other hardware as well.  So what other devices are there that we might run open Zoozer on?  So when the ARM port was still very early some people tried to use their ARM based phones,  route their Android, run a change route in there with some open Zoozer packages in there  simply to have some place to run things on.  It's not something that I've been personally focusing on because phones and tablets often  have the problem that you don't get serial access.  I've tried to do that for the Nexus 9 ones but I never managed to get the serial to actually  work limiting the things that you can then actually try with mainline kernels on there.  But for instance we had open Zoozer running on the Samsung Chromebook, the initial ARM  one, and I got it working on the HP Chromebook 11 as well for some time at least.  Then more recently there are some do-it-yourself kits for building your own laptop so there  are ones available based on the Raspberry Pi and there's also one available from, I  forget the name, it's based on the A64 chip.  And what's the company name?  Only Max, yes, right, the ones with the all-inoxenor and so on, right.  So there's kits like that available for building your own notebooks with a chip that you can  then actually also debug in better ways than you can with consumer devices like Chromebooks  mostly.  Obviously for the record there are servers that are running ARM and we did see the presentation  of the, from Softiron at the keynote last Open Zoozer conference, those devices are available  but well they're not exactly available for small budgets at this point yet.  So they do exist and we have Open Zoozer running on multiple of them but we've usually not  been covering them because it's not what most people here in the audience are actually going  to have access to.  And then to the final part, routers and AS devices and TV boxes are available from lots  of vendors in some cases with device trees and mainline kernel support already available  and in other cases it's possible to do that in fairly easy ways.  And playing with those, failure is always possibility.  So like I said, doing my own electrical circuit for making the headphone output switch to  a serial output on the Nexus 9 didn't quite work so I pretty much gave up those efforts.  I had also worked on a MediaTek based Xiaomi box, TV box that is.  I did not manage to locate the serial pins to get any output from there.  And then there was a Kickstarter project called the Row Board but unfortunately unlike the  initial plans it was actually chipped in a way that no one can actually really tinker  with it so there is no bootloader access to those at all.  There should be some JTEC pins if one locates them and actually wires them up and writes  the necessary drivers to do something with that.  But at this point it's not possible to run them, to run open-suzon on that board.  If you try some of those consumer devices that are not yet documented to work, obviously  chances are that people can't tell you what you need to do if you see this error or if  you don't get output at all.  So basically use external media, don't overwrite the EMMC, think about what you're going to  do when the kernel gets stuck or you overwrite something by accident and maybe your partition  is gone.  Do backups if you can, like do a DD from an Android that is shipping on the device, back  it up to another device.  That's a fairly safe way.  In some cases there are USB based backup solutions.  We've been packaging a few tools to help with that.  So there's the Sanji tools available and I've prepared and need to resubmit the RK  develop tool for Rockchip.  So you may find information what to do for certain types of devices in general but usually  not specific to those devices.  And in particular where the vendor is located it might become difficult to sue them to actually  give you all the GPL sources and instructions on how to actually make something bootable  out of those sources for a particular device.  Now already last year I got my hands on this particular TV box, the Vega S95.  It was one of the first devices with two gigabytes running at that point in time, AMlogic S905  M-chip.  It was the first 64-bit chip from that particular vendor and in the meantime I've managed to  get a chain loaded mainline U-boot to work on there.  So basically I'm loading U-boot via the network and then jumping into the new U-boot so that  we actually have UEFI support in there.  And by now there is also since the 2017 or five version there is MMC support so it's  possible to load things from an SD card.  Tumbleweed kernel is working on there out of the box and just be careful that because  it works on this particular board or box device does not mean that it may work on another  device that you have access to that may require some tweaks.  Maybe the firmware is more restrictive, does not give you a prompt to enter the necessary  boot commands so it may require some more tinkering based on what exactly you want to  do also.  On the next slide I'll go a bit more into how the firmware is structured in this case.  So the reason that I've got chain loading in this case is that I have not yet successfully  tested the tools to make a firmware image out of U-boot that can actually be flashed  onto EMMC or another bootable device there.  Again when thinking about recovery strategies one such strategy might be if the device is  capable of booting on SD card either than doing such experiments on an SD card but unfortunately  in most cases like here the EMMC comes before SD in the enumeration order so basically one  would need to back up the EMMC probably and then do experiments on SD or directly on EMMC.  The good news is that besides those TV boxes there's also development boards available  that have better access to pins and more documentation available.  So by now there is a juice image available for the OdoiC2.  It works out of the box and in order to get to this point I had to hack together some  tools that are packaged as MISON tools.  MISON is the code name for this family of system on chips.  Actually the U-boot bootloader is combined with some ATF like firmware blobs and amended  by certain headers that have description about offset sizes and check sums.  And there was a proprietary tool available from Amlogic for x86 machines.  You can find that in various GitHub repositories.  However we are building our AR64 images inside OBS on AR64 hardware so we can't really execute  x86 binaries even if we were allowed to use x86 binaries without sources to build our packages  in there.  So what I did was write a new tool called AMLbootsig which basically was created by comparing binary  output of input and output files used with the original tool and then starting to write  the tool in such a way that it generates the same output or at least similar output by  now as the original proprietary tool and this is working for this particular board.  If you have other boards I am very happy about any feedback on whether this board works simply  because there is no documentation available for this format and much of this has been  guesswork including the names of struct field and what they actually mean and are supposed  to contain.  Based on the same chip there is another development board available since recently the Nanopi  K2.  I've sent tru.l patches to get it booting and it is working however there is no contra  image for that yet because on the one hand we don't have a Uboot package yet.  The firmware blobs are not yet packaged and my tools are working with that but there simply  is no fully booting juice image yet but basically I keep saying that you need to combine a self  built boot loader with the juice image in order to get it to boot.  S905X is a distinct chip from S905 at this point in time there is only downstream Uboot  support so it is not in mainline.  I have not yet tested our kernel on there.  I do know that the Maison tools do not support this particular chip yet so that will require  some more trial testing and because of all that obviously there is no juice image for  that available yet.  Someone on the mailing list was reporting that he simply took another Linux image and  simply used our juice root of S-Tarball that is obviously an option for many of such cases  but obviously we want to have a proper solution that we can give to our users in LBS.  At Fostom I had shown a TV box running the S90912 chip.  Uboot for that is not yet available mainline.  I have submitted patches to make the mainline kernel boot on there that was what I was showing  at Fostom not here today sadly and the boot image tool does not support the S9012 either  at this point in time.  Now something that I am very proud of having accomplished is I got my hands on a TV box  with a very new Realtek 64 bit sock.  There are unfortunately absolutely no sources available neither for the boot loader nor  for the kernel but after a long time of having no success with this I found a way to actually  boot a U image on there and by now it is possible to boot into an INIT RD.  Since yesterday the patches for that are also integrated into the Linux next tree and hopefully  will make it either into 4.12 or 4.13.  In addition to some of the Rockchip development boards already mentioned earlier there are  also TV boxes.  I know that Matthias Brogge has worked on a TV box at some point with the RK3368.  Did you have success with that yet?  Not fully.  Okay.  I did not have success here yet either but I wanted to mention this for completeness because  at this point in time we are starting to see the first devices, the first consumer devices  ship with a U-boot that is new enough to actually contain Alex Graf's UEFI support.  So this has a modified version of 2017.01 on there and it is possible to reboot into  the Rock USB mode and connect to the board with the RK develop tool that is upcoming  for factory.  However I have not yet managed to actually get into the mask row mode that would be necessary  to flash an updated or modified version of U-boot on there.  Heiko, have you been able to play with any such devices or boards yet?  But I am pretty sure RockTrip is actively working on this and something should be available  in the upcoming U-boot version and then the question is how much changes might actually  be necessary to make it work on not their internal reference boards but the devices  that we actually have access to as mermodels.  Last but not least, last year we had the Taurus Omnia in the room and that is a Wi-Fi router  that was launched on Indiegogo and Michal here in the room is working for the company  that did it.  By now I have open zoos of booting on there.  With me and someone else worked on upstream patches, it is available in the kernel yet.  Already however the U-boot that it was shipping did not have support for our init RD and since  a couple of days, possibly weeks there are patches for mainline available where we are  still waiting for a second revision and then hopefully we should start to be able to boot  open zoos on there without major hacks.  So far for the first part of this talk.  Now if we are looking beyond just getting the hardware to boot our operating system and  having sufficient drivers in there, many of those development boards at least have connectors  where you can actually attach sensors, motors and various other devices and buses.  If we look at the Raspberry Pi for instance, then it has this originally 26 pin now 40  pin connector with various functions available and the way that it works in Raspbian is that  there is a number of DTBO files delivered on the boot partition and you can configure  either manually via the config text or via a tool that they are shipping to have those  DTBO files applied as overlays to the base device tree.  Whereas in the case of mainline kernels and open zoos we do not have any DTBO files yet.  I have started preparing some for the expansion boards and in some cases external sensors  or devices that I had accessible but this is not yet sorted out how this will actually  move forward.  Obviously there are questions of how can we actually possibly reuse snippets for such  device trees that on the one hand need to connect to a board specific device tree but  where basically the functions that each expansion board is providing are always the same.  So this is not yet really solved at this point in time yet and the solution that I have been  testing on open zoos is to simply write a boot script for Uboot that after Uboot has  loaded the device tree, the base device tree, it applies a hard coded set of trees that happen  to match my hardware and afterwards the kernel can simply reuse all the devices in the tree.  If we look further into the future then the idea is that also the kernel should be able  to apply some of those device tree overlays at least when you don't need it to load something  from inside Uboot which is a whole other topic.  It also really depends on live device tree in Uboot.  But for the standard cases the idea is that you would actually install into the Linux  file system a set of DTBO files and you would configure them to be applied in some way possibly  via a system D demon or simply by self written unit file.  Maybe long term it would be even an idea to have a YAST module to configure such well  GPIOs and expansion boards but as long as we don't know how exactly the underlying tools  will look like we haven't really ventured into that territory yet.  So I'm going to show two projects that I've been working from just as examples of what  is possible.  So I had access to a very small microcontroller kit that had a detachable I2C connected sensor  on it.  There was no mainline kernel driver available for this particular chipset and obviously  if you need to write an overlay file yourself the first thing to find out is what you actually  need to write into there to make it work.  On the next slide I will show a bit about generic drivers.  Here is an I2C dev driver where you can generically access I2C devices from user space.  However, what I was looking into was a real kernel driver for this and it's actually pretty  easy to write once you actually have the data sheet available which for those ones here  is available.  So basically I just need to add the finishing touches and get that into mainline kernel and  that is something that anyone having such boards really should look into.  It's easy to do in some cases and is simply the most reliable way to use certain boards  in the driver.  You will find lots of instructions in the web that will tell you to download particular  libraries but a lot of them have licensing and also functional problems when using them  with the mainline kernel and depending on what software you actually have to then combine  it with.  There are more standard drivers in the same category.  The next one I'm still working on.  In theory it should be possible to use for example TPM chips from Infineon with the mainline  kernel.  The current generation is spy based.  The previous one was I2C based.  Unfortunately the spy based ones don't really get recognized although in this case there  are mainline drivers available already.  I'm not sure yet and hope that we can sort that out with them together.  There's a number of Arduino shields available and in case you're not yet aware I've started  documenting in the wiki based on suggestions from Michael.  There are various adapters available that you can actually use for example a Raspberry  Pi board with the 40 pin connector.  From there go to an Arduino connector and then you basically can use almost the whole  range of Arduino boards that are available out there as long as the voltage levels are  compatible and as long as the board that you're using it with has the right functions available  on the pins.  So for example there are boards available that do not have spy implemented in hardware  so you would need to either use a bitbanging on the GPIO pins or simply use another board  that actually has those functions available where a particular hardware design expects  it.  The second project to showcase that I would have loved to talk about more but unfortunately  is very slow going so in case you don't know what Lora is this is a wireless technology  for low powerless wide area networks so you can go for maybe three kilometers have a signal  transmitted by using a certain signal spectrum and there is among others a protocol available  called Lora 1 which unlike some other protocols like for example ZikFox and the new NB IoT  is actually available so that you can run your own gateways.  So basically you can have end to end communication via this technology in theory all running  on open Zuzer.  There are some various GitHub projects to do this in user space however every time you  try to use the spy dev driver on mainline kernels you get a huge one on stack trace  that you're not supposed to do this.  We had some conversations about this at FOSSTEM with some of the spy maintainers and they  do not intend to change this because they're saying that's not the right way to use spy  devices unless that particular use case has been vetted to be absolutely necessary and  their recommended workaround I wouldn't call it solution was to reuse the device tree compatible  from one of those white listed devices instead of the one instead of the literal spy dev  name in order to get around that but that's not really a clean solution and as already  mentioned a number of in particular one very widespreadly used GPIO library for the Raspberry  Pi is under LGPL30 and later whereas most of the software that people are trying to  use with this is under GPL2 which we cannot legally package in OBS unfortunately.  So basically the software for user space is not in a very great shape.  There's no kernel drivers so I was asking about this at a Lora talk at FOSSTEM apparently  no one at that point in time had been working on kernel drivers for those particular chipsets  so I started to do that on my own once again.  I'm not really a networking expert on that socket layer in the Linux kernel so things  have been a bit rough for me but I do have modules available in this particular GitHub  repository that can be compiled against an installed open-to-user kernel.  It's doing some weird hacks like reusing socket identifiers in order to not go beyond  the list of defined protocols so some care must be taken to not run into weird errors  but it's possible to test such things.  Also on the previous slide the sensor driver that I developed I did that as a local kernel  module in the running open-to-user system so I'm very much encouraging people that if  they have a working open-to-user kernel they can actually use that for development of additional  drivers or back ports of additional drivers on top of that as in particular a KMP if you  do it in OBS or if you do it locally you can just build the KMP and forcefully insert  it.  It will show an ugly tamed warning but it works.  After having the spy driver prepared I also set out to write the first ZERDEV based driver  so this is new in 4.11.  It's a way that you can actually enslave a kernel driver to a serial port.  So usually you would get if you have a serial port enabled in your device tree you would  get some TTY whatever device inside the kernel and then you can use user space tools to read  and write from that device.  In this case you can have a kernel driver implementing serial based protocols.  There's initial drivers being prepared for some Bluetooth chipsets that was the main  driver on various boards so on the Raspberry Pi 3 42.2 image it's necessary to call HCI  Attach in order to load the firmware onto the actual Bluetooth module, the Wi-Fi and  Bluetooth module for Bluetooth to work and the idea is to have all this handled by the  kernel.  Similarly, the Pine 64 has a Z-Wave module available for home range wireless communication.  In theory it should be possible to write kernel drivers for all those technologies wherever  it makes sense to abstract a generic interface so that user space no longer needs to know  which hardware exactly it is actually dealing with.  Approaching the end of the talk, cross compilers have been an issue occasionally coming up.  Obviously you can build ARM software inside OBS running on ARM hardware for 32-bit and  64-bit.  With ARM V6 I would get to say that we're currently having for some packages some emulation  problems ever since the G-LiP-C introduced some optimizations so you may see some weird  assertions on ARM V6 but ARM V7 and ARM V8 should work well enough.  However, if you're building a kernel maybe you just want to cross-compilate from your  X86 based notebook.  So there are these cross compilers available just for reference.  They're only suitable for the kernel, the 32-bit version can also be used for UBUT when  using a UBUT internal libGCC copy.  I have prepared in the last days a newly-based ARM cross compiler.  This should work for any firmware development for Cortex-M devices.  I'm not yet sure how far it works for Cortex-A. If anyone is interested in that please give  it a go.  The next step would be to prepare a cross compiler like this for AR64 so that again we  can also have our open-zoos cross compiler available in order to build UBUT for AR64  by a cross.  So that is it for this talk.  We still have some minutes left for your questions.  I know I've talked a lot.  Don't be shy.  It works, yes.  Yeah, you might not know it but in front of you there's a nice Zdo box with your Starming  and M-Star MSO chip 9180 down there on the ground which is capturing the HDMI signal and  giving it back scale to the beamer and to our input source for recording.  At the moment it's running some Android with some Nasty vendor app which is recording the  HDMI and giving it out to the output.  I would like to see it next year on Lightning on Tumbleweed of course.  I think we all agree that that would be nice to have.  However, this is not really a wish concert.  You can express your wishes but it will need someone to actually work on it.  It was difficult to get all the hardware that I've worked on here for this event this year  and of course you can assume that it takes quite some time.  I'm trying to navigate back to a thing that was on the failure slide.  So I did not quite catch the exact number but it sounds like a similar chip as on the  row board so I would not be too hopeful.  So the thing is that I have actually talked to a representative from M-Star about it and  that person said that there is nothing inherently blocking other people from booting something  from via their boot loader such as us as a Linux distribution.  However that depends on the boot loader configuration from the particular vendor.  So basically it's on a case by case basis and in addition to that there are no kernel  drivers upstream for that so you'd need to get access to the sources for the device and  they use their own, I think it's called M-Boot boot loader which is not related to UU boot  so I'm not sure whether sources for that one are available and how well it's documented  what exactly to do with that.  However, if you use Google you will find slides from I think the Narrow Connect 2016 where  their director of 96 boards was mentioning an upcoming M-Star based 96 board which I  think would even have a 64 bit socket on there but obviously that would not help with a particular  device that you have access to the question would rather be would any of all these devices  be realistic to get into a state where they're doing video input and output processing in  the way that you need them for this particular use case?  Exactly because I mean it's probably not really interesting to have Tumbleweed running  on the Tumbleweed kernel running and having a serial output and network device but what  you want is the HDMI input, HDMI output and HDMI capture and hell will freeze over before  you get this without closed source render drivers.  I mean I have all those TV boxes that you mentioned are probably all IPTV boxes, correct?  They don't have any tuners.  Some do, some don't.  Okay because I mean I'm working for about almost 15 years now with satellite setup  boxes and you never ever the only thing where you get an open source driver is the old D-Box  2 which was simply hacked and so and which was actually hacked with with help from the  hardware vendor as is known today.  So all those multimedia boxes are probably hardly worse spending lots of time because  I mean it's fun for for education to have the kernel booting but you often cannot do  really much interesting things with it because you will never be able to get or never.  It's unlikely that you will get video in or out there apart the only one where this really  works out of Raspberry Pi is because they have the rather open drivers.  That's that's my.  And even there the driver situation is progressing very slowly at this point.  Yeah but at least you have to have access to the encoder and the decoder and stuff and  so you can you can actually use this.  So but it's really interesting and I think I forgot to mention that after I did the the  initial patch set for for the S905, Bay Libre was contracted to do mainline enablement for  for the amlogic chips that are being used in many of those Chinese TV boxes.  And in the photo 12 kernel, HDMI should be working as output.  And I believe there's also some work on on video encoding, I thought, but I'm not entirely  sure.  So it really it will depend on the particular vendor.  So we've been in contact with Rockchip and there are like G streamer packages and other  open source bits available.  Some vendors are trying real hard to to be a good open source citizen.  But if you buy the box, that's not the state that they will actually ship at this point.  And well, it's your right that it will take time and effort to be surprised in a positive  way because I'm actually looking for people asking me for quite some years.  What's an open source TV box to buy?  And I say, yeah, there is none, basically.  I mean, there are all those all those.  I'm usually hacking on satellite TV set of boxes.  And there are different different states of closed, but they all have closed source drivers  and they're all crap, basically.  So it's it's just a selection of crap that you can get.  So I would like to be positively surprised, but I won't hold my breath for it.  So you do have a point there and I have to maybe point out that when I'm working on some  of those TV boxes, I'm not working on the TV boxes in order to get video encoding or  TV streaming working, but rather I'm using that as a means to get early access to some  of the chips as long as no development boards are available.  So yes, my use case is not really getting to to that full-fledged system, but I found  that if you actually document and make initial patches available so that people can have  a semi-working system, then more people are likely to contribute to that port than if you're  just sitting for a box where you're not getting where you're having a black screen on HDMI  and you're not getting anything sensible coming out of the serial system.  So it depends on how large the community is and obviously there's a much larger Sunshee  community than for some of those others more odd vendors that I've mentioned here.  And well, yes, it depends on individuals to contribute drivers to make things work and  it's questionable whether we will ever get to 100%.  So one thing that I omitted from this talk simply because there's been no real progress  is Mali.  So there's often confusion in that if you actually want to have graphic output on a  board via HDMI connector or whatever the board offers, you don't need to have Mali drivers.  Mali drivers are only for 3D acceleration.  They're not currently mainline available.  There are GPL drivers available and I even have some of them packaged in Contrip Mali.  However, they keep breaking whenever the kernel gets updated and it will require a lot of  documentation and tinkering how to find out which version of the driver to combine with  which device tree overlay and which binary user space download from whatever external  source in order to possibly make that work.  Have you looked into the Halium project?  Halium project is like what we eat.  Like in honeycomb.  Halium.  H-A-L-L-I-U-M.  So the project that Plasma phone and UB ports people started so that these devices, these  platforms can run on different devices.  Okay, well, maybe you can take a look at it.  It could make your life easy somehow, somewhat, and being friends with them could be useful  for you, maybe.  In which way could you describe that?  Okay, well, I'm not speaking for the project, right?  But the idea is that you know only Pibris, for example.  So when you try to port Linux system into mostly phone devices and tablets, you have  the problem that you get the driver for Android, but you don't get for anything else.  And while you've been mostly talking about how getting output from HDMI is success, well,  in practice it's not really success unless you just want to show like a static thing,  right?  As long as you want to have humans interacting with it and a touchscreen, you want to have  accelerated graphics.  So what Yola started doing was using Android graphics drivers.  So basically you're saying that the software project is making Linux compatible user space  parts available to use an Android kernel with an open-to-the-file system plus those additions?  So the thing is that Pibris, for example, was there for a while, but it was only available  for some devices.  What they're trying to do is to kind of get a pull-off devices, mostly phones and tablets,  that are supported.  Like if I told you today, port Plasma phone to my device, you would tell me, well, I  don't really know where to start from, right?  And well, there's going to be these kind of projects that will have Halim configurations  and kernel configurations so that you can get device to boot and this kind of stuff.  But anyways, if you think it's interesting, tell me later and I will get you in touch  with the people who actually know about the project and maybe you can be friends.  I don't know.  Thank you for bringing it up.  And I assume it may be interesting to some people in the audience or viewing the recording.  To me, personally, obviously the goal is to have open-zoos are working and that in the  end requires to have at some point the open-zoos are kernel working where I understand that  would then not no longer be necessary.  For the questions?  So you've highlighted a vast range of hardware, et cetera, and a lot of it doesn't appear  to have upstream support, whether it be in the kernel or U-boot.  Do you feel that ARM vendors are getting better at upstreaming or is the situation still the  same where the upstreaming of platforms is still really bad?  And be honest.  I'm trying to think about the numbers in my head right now, but if you go through my slides  afterwards, I think you will find quite a disappointingly high number of new boards where vendors are  still sticking to the old fire and forget BSP model where they do like a U-boot port  once based on whatever old version is.  In the end, I think it's like a trickle-down model that is still being used in many cases.  So a particular chip vendor makes a U-boot port, he passes that on to the board manufacturer,  they maybe do a few or three changes, but no major rebases like that, and that then  gets shipped and then it doesn't see any updates.  I have seen, for example, well, NXP for a very long time has been active in both the  U-boot community and the kernel community.  Marvell is also very active in those spaces, well, at least Marvell Embedded Business Unit,  and there is a number of other vendors that are also doing great code, in particular on  the kernel.  Obviously, there are some commercial like server vendors that don't need to do any U-boot work  because they're using like AMI commercial firmware, that simply works.  But I still feel that despite a lot of talks on this topic and lobbying, not all companies  in particular, when they're like new to Linux and only doing Android, haven't really learned  the lesson yet.  And if you see any ways how Arn, Linaro, or any other organization, maybe the Linux  Foundation or Free Software, whatever can help with that, that would be absolutely awesome.  On the other hand, I have seen individual companies getting more involved with open  source, so there are certainly encouraging developments within the market.  Like for example, RockTrip is getting more and more active with their new 64-bit models  or in other cases, companies are simply seeing in need either being driven by enterprise distributions  or for whatever reasons to contract other people to do that upstreaming work for them  and still doing like to some degree parallel initial in-house development that will never  go upstream and then have something that will go upstream, but in the end, there's still  both parts of it.  So things that are, have been improving and things that are still bad.  Hello.  Have you heard of the Geekbox?  It's a set-up box with an arcade 30...  You have?  Yes.  Oh, okay.  I worked on the U-Boot port for that one.  At this point in time, unfortunately, there is only serial output working.  There's a bit more drivers contributed by RockTrip by now, but last time I tested it  before the conference, it was not yet ready to really boot open the user.  But what I have done on there is I flashed an Android-style, self-built kernel image  using the upstream kernel onto the boot partition and used that with an open-zoom-zeroot-faz  file system.  So it's possible to run open-zoom on there if you're willing to get your hands dirty.  Okay.  So, and the next thing is I've got a Remix Mini.  If you want, you can take a look at it later on.  Thank you very much.  Any further questions?  And thank you very much for your attention.  I hope that there was something for your hardware in this talk.  If not, come and talk to us about whether it's possible to get it supported or how likely  something is to get done.  And there is the open-zoom-z-arm mailing list to ask questions or follow things that are  happening.  I admit that I don't usually spam people there with all the stuff that I'm doing, but you  can see the category arm devices on the open-zoom-z-wiki where most boards that have been enabled  have at least some stoppage that you can see someone has already been looking into it.  If not, if you have some device and it's working, please document it in the wiki and, yeah,  contributions are always very welcome.  This is not a one-man show.  So thank you for your support in doing this, also in providing test feedback as new kernels  get updated or new images come out.  And thank you again.
openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_0_203.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_204_287.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_288_335.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_336_467.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_468_515.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_516_587.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_588_671.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_672_719.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_720_1127.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_1128_2687.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_2688_2735.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_2736_6587.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_6588_10043.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_10044_10115.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_10116_10175.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_10176_11075.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_11076_12095.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_12096_12155.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_12156_13103.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_13104_13151.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_13152_14099.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_14100_14255.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_14256_14711.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_14712_18899.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_18900_20627.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_20628_22259.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_22260_23207.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_23208_23291.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_23292_23363.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_23364_23783.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_23784_24551.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_24552_26951.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_26952_27551.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_27552_28463.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_28464_29351.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_29352_32675.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_32676_32783.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_32784_35375.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_35376_36023.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_36024_36839.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_36840_37691.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_37692_38435.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_38436_38531.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_38532_39287.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_39288_39359.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_39360_39575.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_39576_43307.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_43308_47087.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_47088_50879.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_50880_54179.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_54180_55499.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_55500_56327.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_56328_56435.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_56436_56951.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_56952_59027.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_59028_61667.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_61668_63239.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_63240_63287.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_63288_63719.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_63720_68579.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_68580_81719.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_81720_81923.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_81924_83291.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_83292_84047.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_84048_84239.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_84240_84299.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_84300_84863.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_84864_84971.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_84972_85535.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_85536_85583.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_85584_85631.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_85632_85679.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_85680_86231.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_86232_86279.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_86280_89831.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_89832_89999.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_90000_90047.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_90048_90095.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_90096_90299.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_90300_91307.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_91308_91499.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_91500_91547.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_91548_91607.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_91608_91727.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_91728_102563.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_102564_102611.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_102612_102659.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_102660_107951.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_107952_107999.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_108000_108047.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_108048_108095.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_108096_108143.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_108144_108191.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_108192_109763.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_109764_109823.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_109824_109871.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_109872_109919.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_109920_109979.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_109980_110039.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_110040_111119.png openSUSE_Conference_2017_openSUSE_ARM_boards_updat_qC5y5xg9Eu0_111120_111241.png