Call your NetBSD
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.
Pronchery, Pierre
After focusing on improving NetBSD support for tablet hardware, NetBSD enthusiast and DeforaOS developer Pierre Pronchery (khorben@) is working on running NetBSD on smartphone hardware, with the OMAP-based Nokia N900 as the main target. After a quick summary of the different steps taken, he will introduce the user interface, installation procedure and underlying specificities to this setup. If all goes well, he will even be able to give a call! NetBSD is a very portable Operating System, which supports a plethora of hardware devices based on an ARM CPU and SoC (System on a Chip). Among them is the OMAP family from Texas Instruments; popularized by the BeagleBoard demonstration board, it is well supported by a number of Open Source systems. As it happens, there is at least one smartphone built around the same platform, namely the N900 from Nokia. Being well supported by Linux already, it is an ideal candidate for introducing modern telephony support to NetBSD. The user interface used as part of this effort originates from the DeforaOS project. Its graphical environment is based on the Gtk+ visual toolkit, and has already been declined for several embedded designs, including a phone: the Openmoko Freerunner. Introduced within pkgsrc as of the 2012Q4 release, it will hopefully provide a functional telephony environment on a NetBSD-based phone by the time of the presentation.
 Okay, so let's go. Thanks everyone for joining. Hi, good morning. Usually I don't like to speak on mornings, but since I'm based in Germany, I like to travel this way because it makes the Saturday a worst day, and I'm actually awake. Which is good because I spent most of last night writing these slides. I'm still heavily working on this. This meaning I'm trying to port net-psd onto this phone. I'm not the first guy to do this, but first let's say who I am. So I'm Pierre Pocherie, as I mentioned, I'm based in Germany. I'm freelance. I've been working on operating system development as a hobby for many years now, about 10 years, and I'm a net-psd developer as of May last year, so it's been a little more than a year now. So first I'm going to say why I'm doing this because there's a lot of history behind it, lots of different reasons, and I happen to have the Nokia N900 here. I got it a few years ago. I'm going to explain how. It's kind of a funny story. I'm going to tell a bit about the ARM architecture, because this phone runs an ARM processor, and net-psd was already running on ARM before I started working on this. I'm going to tell a bit about the net-psd in particular. Of course, this work that I'm doing here is not exactly trivial, so I faced a number of challenges, and by the time I submitted my talk and hadn't really started with this work, I was hoping I would be able to give a phone call with this hardware. Unfortunately, it's not the case, but I have still quite a few things to say. I'm going, of course, to mention where I am right now with this work, and what I want to run on this phone, the Dufrawa project, which is the result of my work as a hobbyist, about operating system development, and I'm going to speak a bit about how I see the future, what I want to work on after this talk. All right, but first, a lot of things happened for in the last 13, 15 years. So, a first friend gave me a Linux CD back in 1999, when I was still 18. My computer was not really happy with Linux, so I got a free-based CD shipped from the US, because at the time I didn't even have DSL at home, I had only an old PST and Modem. Although free-based CD was working good, I sticked with Linux for a while, then I played with open-based on some circuit hardware. Then a friend of mine got a Zoros PDA. It was a small device, I have a picture after these few slides, that was embedded at a retractable screen, which could pivot, and the device could become a tablet. In the meantime, I switched my desktop and laptop environment to an SD. I bought myself a Zoros PDA as well. I tried open-based on the Zoros PDA, it was working very slow, but working at the time. So then, my ex-boyfriend got invited to a bar camp. I was playing with this Zoros during her talk. One of the bar camp attenders saw me doing this. I began to work after that on the Diffresd desktop. I got some of it to work on the Zoros on OpenBSD. I attended the CCC camp near Berlin, I was 2007, I think. I was doing my birthday, my ex-boyfriend offered me an OpenMoco phone, which was an open hardware phone. I ported the Diffresd desktop to the OpenMoco phone, so this is not the first phone I'm working on. The bar camp attender happened to be at the CCC camp too. He was head of a hosting company in France. As part of his research and development initiative, we began to sell the OpenMco coffee runner. We sold Europe-wide. We created a linse distribution to support it, which was Debian-based, because at the time there was hardware, but none of the software solutions were really satisfying to us, and we had to support it, so we decided to take Debian and improve it. OpenMoco was end of life after that. Splitways with Versteck, who was reselling this device. Another friend gave me some Spark64 boxes. I got a lot more involved with NetBSD doing this, because I was trying to run my desktop on Spark, and so I ported my Diffresd desktop on Spark, on NetBSD. Then Nokia invited me to join a developer event, where they gave me an N900, this device here, which is not exactly a phone, but can be used as a phone. The bar tender pointed me to a contest. The contest was about creating an open source software-based tablet, so I took my software again, adapted it to the tablet environment. I co-won the contest this way. I shared the prize with another guy who was doing Android stuff. Yet another friend put in NetBSD on the N900, and he's the reason why I'm here. After giving a talk about the withapp tablet, which is the one with which I co-won this contest, I promised to work on this phone next. I applied to BSD Can, and I had basically nothing working at the time. I tested Maple syrup for the first time in Canada two days ago, and here I am in front of you. I need some water. How was the maple syrup? Awesome. I love it. I'm going to get a keg when I get back. I'm going to go through the airport with this. I'm going to have it in the airplane with me. Share it with you. Great. I will make sure that I have that with me on the plane, because I won't lose it. That would be a shame. Yeah. It's funny. Usually there's a leaker over there, and here maybe it's a local leaker. Equivalent. I'm sort of sugar addicted anyway. Yeah, so this is the Zorus PDA. So I had been... OpenBSD was ported on this, and I ported my software on OpenBSD on this at the time. A few years back. This is the OpenMoco Free Runner. It was developed by an off-spin of FIC, which was a Taiwanese which is a Taiwanese manufacturer. Usually they do mainboards and consumer electronics for auto companies, and they had this research group started as a spin-off, and OpenMoco was therefore developed as an open hardware solution in Roser and Linux. Everything open-source, the hardware included. You can still find it online if you want, but it's a bit outdated now, the hardware. This is the WeTab. It's not really great here on this slide, black and black, but I'm sorry I didn't bring it this time. You can watch my TouchonetBSD talk which I gave at EuroBSDCon, or I presented this a bit longer. This is D4OS, what is this? Just a logo. I'm just teasing you now. I'm going to show a bit more of its new slides. Alright, this is the 900, which you can also see here in my hand. It has quite a big screen. Keyboard, which is great for debugging. USB ports, two cameras, and it's the it's the one, two, three, four device in this series, the N series of Nokia, I mean the N series tablet of Nokia, but the first one to have a GSM chip. It's based on Nomap, which is an ARM socket system on a chip integrated solution, ARM based. It has a reasonably fast processor, quite a bit of RAM especially by the time for an updated platform. It was released late 2009. The touch screen is single touch, but other than that, it's pretty modern. Lots and lots of connectivity, Bluetooth, GPS, GSM, FM receiver, transmitter, as I mentioned, it's a 3G. And it ships with native Linux already when it was released. Memo was based on different GNU Linux. Here I use the pass because Memo is pretty much dead, unfortunately. So this is a hybrid tablet with a very funny platform. It's switched from DTK Plus for user interface to Qt with the 900. Most components are open source though. There is a good community around the project which is still alive even if Nokia gave up supporting it. I think now there is an independent company or group taking care of the project, so it was migrated to a new platform, but the Wiki still exists and there is a lot of documentation and so on. So it died because of some debatable political decisions at Nokia where they partnered for a while with Intel. Intel had Moblin, Nokia had Memo, it became Migo, but Intel was doing its thing and Nokia was doing its thing and in the end it didn't really turn out really well. So this is the outcome of it. The one and only Migo phone publicly released and available. And it was really Memo with some compatibility layer to be able to claim it was Migo. So really it's still Debian based and so on. Whereas Migo supposedly supports only LPMs. Which is kind of poor. But it's dead anyway. Now it's Tizen and something else. But there is a new company called Jola which was created by some ex-Nokia employees which is working on a new phone and is continuing the Migo development their own way. So we can watch online there are a few presentations on how it should look like and I think they expect to launch next month also in China. But anyway, what's good for us now is that there was lots of documentation available and a working code for almost everything. GPL but still something to read in order to try to understand how to get all of this working. So it looks like this when it was released. So very well integrated to-do lists, calendar, it's connected to exchange. So it was already windows-oriented at the time. Lots of applications, very easy to customize and so on. So now let's get a little bit more into details. If you don't know much about ARM, I believe you mostly don't know about ARM. But anyway, it looks very much like a regular PC inside. So you get CPUs and DDR RAM, some storage space, there are some buses, it's a PCI but it's sort of the same. There is user input, lots of interfaces, connectors, 3D acceleration for graphics, video acceleration. However, there are additional constraints. It's a mobile device which means it has to be autonomous. So there is a battery. You have strong constraints on voltage, frequencies, how long it's going to run if you set the CPU a bit too much. Of course the physical size is a constraint also here, it has to fit your pocket. However, nothing prevents running BSD on it, except maybe in the future for secure boot, which is the new way to boot devices coming up with UEFI and so on. Whereas on x86 secure boot still allows you to boot whichever system you want, you can disable it. On ARM it's not the case. So it's pretty much, now it's going to be a completely closed platform because all of the new devices shipping with Windows 8, or most of them, supposedly you cannot jailbreak them and run your own OS. I'm sure people will figure it out, but it's getting more and more difficult with this new hardware. So I prefer not to invest in this and work on my own shit. So, very short introduction to the ARM processor itself. It's risk based. There is now 64 bits version but usually you will find it in so little bits and in little Indian, although it supports also big Indian. The company ARM doesn't manufacture any processor themselves. They license the design to bigger companies like Samsung or TixxS Instruments and so on. There are lots of different generations. This company has been around for many years. Maybe sorry or something like that, I don't remember. And as a consequence, there are as many different ARM platforms as there are combinations of processor design generations and instances of like boards and chipsets. So it's not really just one coherent platform or sort of coherent like X86. You cannot run just any ARM code on any ARM processor. It's not many this way. So it's a bit particular and then about the OMAP solution in particular. So it's based around a general purpose ARM core which is completed by lots of different core processors and extension chips. It was popularized in the open source world by the Bigel Board which is based around the third generation of the OMAP processor, 3530 and it's luckily very similar to what's inside the 9900. It has a different name, 3430 but really it's the same chip inside. It's just that the packaging is different because I guess they had to they needed a different version of their core for smaller constraints, different physical formats and so on. So the Bigel Board looks like this. You have the main processor here. Lots of connectors companionships here. I guess one of them is the power companion which actually has a lot more connectors because the OMAP processor doesn't do much in itself in terms of user input and so on. It just exposes buses basically. So yeah, there is RAM and everything fits in a small board which is maybe 6 centimeters wide where it's 3 inches, that's 7.50 or something like that. 7 centimeters. So main TPU has inter-uplines, like you would have on x86. The buses are not PCI or ISAR whatever, they are I2C, SPI, GPIO and so on. GPIO in particular means general purpose input-output which means it's just a bunch of pins and you can use them whatever way you want. They can be input pins or output pins and your input or output data or you can abuse them as interact pins where you just listen to whatever is happening and the chips that knows about this and you tell it to wake you up when some event is happening. Either when the pin is low or when it's high meaning 1 or 0 basically or when it's changing state which means then that it's edge triggered. So level triggered is when it's a given level, it wakes you up low or high and edge triggered is when it's going from low to high or high to low. This is going to be very important when developing this. So you have after the OMAP processor, a companion processor typically interrupting inside the OMAP CPU so it has a special line, special connection to the CPU on the PCB so it's however connected on a separate bus and you have lots of additional processors between each of the different functionalities that you're going to require like Wi-Fi or Bluetooth or you name it. It's just lots and lots of different processors and typically they interrupt via GPIO pins which means they are connected to the main processor over the GPIO bus. Sorry if I'm very fast here I have a lot to cover. Just tell me if there is anything you want to emphasize on. Just as a reminder, this is the old NetBSD which was also ARM based. So it was just a regular toaster which was extended with some embedded board running NetBSD and it was fully operational using the NetBSD system. Alright, so NetBSD EVB ARM is the actual port that I'm using for doing this. It means evaluation board. Typically companies like the SES instruments and others develop typical designs for people to grasp the platform and experiment and prototype before shipping an actual product and this is pretty much what the big old board is. And this port explicitly supports aims at supporting as many of such prototype boards as possible. And JSON top is the maintainer of this port. Alright, so if you look at how many kernel configuration files are available right now inside this port you have quite a few boards which are supported. Some of them are maybe familiar to you like the panda board or the raspberry pi the Anandjord is here. You have the big old board, the big old board exam, the plain big old board and a bunch of others. They are not all all map, of course. There are lots of different designs from Samsung from multi-eye, the toaster is there and so on. So NetBSD why is it a cool platform and why is it found on so many devices? It's because it's clean, so it's portable and it's portable so it has to be clean. Which is a nice way to abstract the system and it means there are lots of constraints in the way all of the drivers are organized and the way the system is is organized and what you have to deal with therefore when you work on this. So bus access is abstracted typically you use the same interface to talk on different buses. The same APIs are used as much as possible across different architectures which means you can typically only expose what's supported by all of them. And so specificities are kind of tricky to to get by in some cases. Especially if you want to write generic code. This was a problem in my case. So the device tree model in particular you have a virtual root device which is just a way on which to attach the real physical buses. Then devices attach on buses. They have exactly one parent node so it's really just like a tree. And in turn these devices may expose more buses and have more other devices attaching to them and so on. That's what you see in the message when you boot the system on iCleanlux which is just a big soup. On NBSD it's really telling you okay this device attaches to which bus going to this other device going to the root node. And with all of that devices typically register sorry on interrupt lines and they handle them. And that's pretty much all they do. Interrupts. It's a very important notion here. Typically whatever happens on a device there is an interrupt for it. Typically when you touch the screen there's going to be an interrupt telling the processor okay there was an event, handle it now. Interrupts are expensive because they are directly you can only have as many as you have CPU cycles. And they occur all the time because whatever happens the clock tick watchdog and alarm user interfacing packets on the network it's all going to be interrupts. So you have to handle them as fast as possible with therefore as little code as possible. And it's forbidden to sleep and be lazy while handling an interrupt. Because the longer you sleep the more interrupts you lose. Because when you handle one you cannot handle others. So typically you just differ or you set a flag or whatever and you accuse some job to be done and then you're back to regular mode and the scheduler is going to do your job. So for this you have different mechanisms. One of them is the work use but then you have also software interrupts or bunch of other stuff. I should have listed them here maybe but next time. So as a consequence I had to write dozens of writers because there are lots of different devices especially on a smartphone when you have to handle audio, USB, touch screen, keyboard all of the network interfaces and so on. Of course this represents a lot of different interrupts. Not enough I mean there are too many for the main processor. And as I mentioned I mentioned separate buses. The interrupts are on GPIO which is one bus and devices are usually on I2C or on SPI and in different buses and in NetBSD you can only attach to one bus. So it's really tricky to address this model. The bad news is yes it's tricky. However there are mechanisms to address that which are actually pretty good just that you know about them when I started and it took me a while. So yes let's get on with it. So let's prepare. Let's make sure the NoCard and Android boots on a microSD card. So typically what you do when you walk on this you open the phone like the Steers is a great tool to do that because you have to be gentle because you have to do it all the time. So when it opens you have the battery here and so on you can remove it. And the microSD slot is here which is pretty good because you can remove the card put it on your laptop and test whatever you have. It's however very slow and it requires some modifications to the phone in the first place. You have to switch it to developer mode with the regular firmware flashing tool. I think the wiki page for this disappeared or is no longer reachable from the migration of Memo from the Nokia platform to the new one. But there is another page called Memo Flasher which sort of covers it. You have to run this Flasher tool, check the flags and be very careful there. So it would be good to find a cache for this old page and put it online again. Basically you have to flash the bootloader to enable multi-boot so that it boots no longer just on flash but on your card optionally. And you have to set the phone inside developer mode because otherwise some watchdogs are not addressed and the phone just reboots after like 10 seconds. Which is a pain when you don't have enough time to boot and see whatever is happening and then the phone reboots. Yeah. So the alternative is to film it. But yeah. So can you develop any of this or at least have a model of the development of your phone machine and you have to do all of the hardware for all of the stuff? So the question is if there is some emulation platform a way to emulate the hardware and test it on emulation, right? There is a special QMU fork aimed at emulating the bigger board which was also extended a bit for the 900. However the code is very difficult to compile outside of Linux. I managed to do that then I managed to emulate a bigger board bootloader and for this you had to create a fake flash file. However for some reason it refused my flash file because the checksome was awesome. And I followed some weird instructions from a Chinese guy somewhere on Google code whatever because it was the only place where I found this really new available. Typically other than that the only thing you can do is take an existing Migo image which is going to be like 4 gigs and you have to start from there. Or yeah for the flash it's a bit smaller but I didn't want to start from a complex system I wanted to start from scratch and so it's really tricky. You have to run Linux or spend a lot of time compiling it and then I wasn't able to actually get NetVisit to run on this. Yeah. There has been some development in the last couple of months that there is a port of QMU that does work better and will lose some net net that's right. Yeah. Not one map 3 yet. But yes we're getting there. So yes be very careful and if you can use emulation. However emulation is not always 100% like the hardware. So sometimes you have something working on emulation and not on hardware or the other way around and then it's another challenge altogether to figure out what is really right and how you should address everything so it's never 100% solution. So if you want to boot the 900 and microSD you need to set up partitions like this. Inside the MBR you want your NetVisit partition to be the first one. The third one has to be a DOS FAT on which you put a UIMH file and the boot loader is going to load it and start the kernel. And then it's up to your kernel to find whatever it has to boot. So good news is we can use FFS and create it this way. You can just untar the different sets. Run makedev and slashdev which is going to help the booting faster. The FSTab looks like this. Then you set the RC.conf to be configured. You can even enable xdm here and if things are alright it's going to boot x all the way through. It needs to be very patient right now but I guess this is also going to be worked on. We know already why some things are very slow. So yes, it's slow. It's a tedious test procedure that I already mentioned. You have no network boots. You have no serial line interface on this phone. Actually there is one but it's low voltage and even if you use the regular consumer USB serial adapter's fallout voltage it's still too high for this phone and you're going to break it. So we know what the serial connections are but they are a bit tricky to connect to and I don't want to solder on my phone. They are under the battery cover and there are like 20 of them and you have to pick the right ones. I don't remember what the rest is. Maybe JTAG, I'm not even sure. So yes, another tricky part is that initially I had no keyboard support. So I could not even go into the debugger and type in stuff. I had to update the microsd card every time and boot it again. That's a very, very slow process. On top of that, the documentation is extensive which is good but it means the data sheet for the main processor is over 3,000 pages. You don't need to read all of this if you want to instead what's going on. You're going to have to read a lot and read it again and again and again. The companionship for keyboard support is another 1,000 pages. So the way I worked on this is I really forced myself to do one change at a time and test every time and try to remember write down, note inside the code what was working, what wasn't in combination with what and then, yeah not get stuck on one given bug because sometimes you don't understand enough of the platform to understand what's going on and so if you lose hours on this it's just lost. Often you just switch to something else and understand something about the first thing while doing this other thing and you come back to the first one test and go back and forth this way at least it worked for me. So anyway the first step was to differentiate the platform with the Bigelboard because even if there are very similar platforms the Bigelboard has a serial line and you don't and it doesn't have a screen and you do. So the first thing was to change the Bigelboard initialization code to enable the screen and disable the serial line for the console. Otherwise you just had a black screen which is useless. So I have introduced the Canon Option OMAP 34 30 for this which is not the cleanest way to do this but for now it works because it's the only platform that has this chipset at the moment and we're going to have to find another mechanism if we ever have more devices this way. So that's minor really. Challenge 2 I mentioned GPIO many sensors just attach on GPIO and tell you okay I'm a button when I'm low it means I'm pressed when I'm high it means I'm not pressed released and you just they change states and you just want to know when they change states and you report it. Unfortunately it took me a while to figure out that the OMAP GPIO bus driver supported edge interrupts but only rising or falling. Low from too high or high to low. So I just had to add these two lines to add support for this and then I could not only see buttons being pushed but also being released. And it's also this way for many sensors like when you insert a node in your plug inside the jack here it's also on GPIO yes? How do you distinguish between interrupts and interrupts and what's data in that scenario? It's hard coded basically you know this device is going to be on this GPIO pin and you know it's going to be interrupting or that its data can be abused as interrupts or you can tell okay I'm always going to output data here or I'm always going to input data here. So in a way interrupts are just inputs but you react automatically on this input. But what I mean is if you're sending data where you've got open serial writing by definition which means your signal is going high and low all the time how do you distinguish between data of the signal going high and low and an interrupt event with the signal going higher and low? I think the way it's done you're not going to be the same open? Yes. So either your data is just one bit in which case it doesn't matter because just at the time when you need the data you check if it's high or low and then it's 0 or 1 or you're using multiple GPIO pins in this case you can transfer a word at a time and you have another pin which is working as interrupts which is telling you okay read now read now, read now, read now and then you can use pretty much what happens in a regular bus. Yeah I think generally just to clarify the confusion and then I may be unclear about this but you can't usually use a single GDI token for both at the same time you set up as an interrupt and then you know oh I'm going to be an interrupt on that and support it and I'm going to do the first line of the slide and then we can read the message. Okay maybe this is confusing. Yes so say you have a button and you press it. It's an input pin because when it's pressed it's going to return 1 and when it's released it's going to return 0 and you abuse it as an interrupt. Really it's input and you react when this input changes. You tell the processor okay monitor this pin and wake me up when there is a change. So when you're in some circumstances your data and your interrupt are the same? Yes that's right. Yeah. This isn't for your data which is fast. This is for user function buttons. Yeah. Slow enough that you can get your interrupt service in time to read what the pin state is so that you can know whether it's up or down the rest of the system. However sometimes it gets really hairy and people implement I2C over GPIO which is really really slow but in some cases you want this. Yeah. You don't have an I2C bus and you want to talk to some I2C device because some devices only come bundled this way and so you have to do this. We support this in the BSD by the way. We have a driver for this. Yes that's right. But in my case I need to handle I2C devices which interrupts which is next challenge. Now it gets interesting because of course you can only attach to one bus but then this I2C device is going to tell you okay I'm the keyboard here and I want you to read me now because the user just pressed the key and yeah so how is this happening? Well GPIO pins are mapped as interrupts. It's not specific to ARM or as a whole. It's only a few ARM platforms which are implemented this way. I don't know if it's just an NBSD thing or some kind of official thing for a given platform. But typically on ARM interrupts are integers. You have the system ones which go from like 0 to 31 or something like this and then you have your own convention and you start virtual interrupts from typically GPIO buses on starting on another number altogether. So here in our case we have the OMAP GPIO bus driver which is found on this internal bus at this address for accessing registers and checking the status of the bus and everything. It takes this much amount of memory to address the registers and it's going to interrupt starting at 96 and this one has 32 pins. So from 96 to 96 plus 31 you have virtual interrupts and you really will catch interrupts coming from GPIO while hooking the same way as you would with the main CPU. So this is really practical and it means you can handle interrupts from different buses using GPIO lines and it's transparent because it's just a number with the same interface. You establish the interrupt, you register it and then you can handle it. So there is generic code in NBSD for this which is called PIC code. I don't know why I guess it's very similar to what microcontrollers do. Yeah, okay. Programmer will interrupt the controller. That makes sense. Alright, so this way you can easily handle interrupts while having a device on the bus which typically doesn't. But in practice this breaks portability because it means in order to see an SPI code you will try to hook interrupts. But these devices may exist on different platforms where interrupts are not integers. There are something else. Or there are no interrupts available for these devices in the first place. So it's typically machine dependent. This code is different on each and every architecture. Or you cannot assume it's going to be the same. So I proposed a patch at some point adding an interrupt locator to these buses but it was rejected. And this was the right decision because it's just not the right way to handle this. It's not portable. So I created my own branch called Corbin900 where I have committed this version of the code that I wrote. And inside the main tree I committed stuff with hardcoded values because there was no way I could obtain these values from the kernel configuration file and there was no way of doing things. In Linux it's well hardcoded inside the code also. Inside the code specific to each and every different board. So you don't have a single file where you can just tweak things and have a working kernel directly. You need specific code for each and every one of the platforms, young platforms. All right. So for the keypad in particular it was very, very tricky because the keypad is on the companion ship. The companion ship is on I2C. It interrupts on the main CPU because it's a special device which is located on the main CPU. Talking to the I2C bus requires sleeping because you send data and you wait for the answer. But you're not allowed to sleep in interrupt contexts. So typically you just want to defer the hand-rock. You tell the scheduler to wake you up when it's available and you just hold the interrupt. But the interrupt is not handled in the first place which means it's just coming back to you repeatedly and the scheduler is never giving you the chance to address it. Which means you need to disable the interrupt while you handle it and re-enable it again. And so far in NBSD for ARM at least it was impossible to do this. It was assumed that devices would just register an interrupt and never disable it. Just handle them all the time. And in this case it's not possible. So I've implemented this. I had to modify the PIC code to allow for this. In a way that's affecting much more hardware than just this one. So I couldn't commit it directly. I have to check all of the other drivers to see if they return the value that I expect or not. Did I mention it here? Yes. So typically what in practice the compendium chip it gets even worse. It's connected to five different addresses on two different I2C buses. Meaning the keypad registers are reachable on one given address not on the others. But the interrupt handling address is on a separate place. So what I do is my main interrupt handler is differing a first handler returning 0 to abuse whatever was done before and telling disabled interrupts it's not handled yet. This first handler uses a global handler to wake the keyboard driver at this other address and it should use another handler again at lower priority. So this intermediate handler reports the key pressed by accessing the bus at the right address and then the other handler that's running at lower priority, very important re-enables the interrupt because otherwise you don't get your key pressed and you lose it and you get back to step one. And yeah, this took me a while to figure out with lots of booting and black screens because this code happens before the initialization of the frame buffer. And if it keeps interrupting all the time it never goes further and you just wait. Is it going to pop up again? Please. Do you ever want the reason you're not the solder serial for an undercurrent? Well, I figured it out pretty quickly and I found another way. I was abusing other interrupts so I wrote a specific driver for just differing this work and waking up the other driver to do all of this initialization stuff. Once the frame buffer was started so typically I was booting an interrupt for the touch screen and I was just pressing on the screen and then my keyboard code was starting and I saw how it crashed. And then I was asking on IOC how can I solve this and thankfully I got an answer usually pretty fast. Thanks guys. So are you actually removing the interrupt handler for the other stuff that's handling or are you just masking them in the right way? So what the pick code does is it keeps a list and then it masks it again for the next time which means if you disable the interrupt using a separate code that I added during interrupt context it's going to be re-enabled anyway because after you disable the interrupt this pick code is listing whatever you did and then it's enabling interrupts again. So it means I had to really patch deep down the pick code for this because even if I was adding code to disable and tell the processor to stop masking it I don't even remember which one is mask or unmask you tell the processor to stop waking you up when there is an interrupt but when the pick code was done handling every interrupt it was just re-enabling all of the ones it had just handled. So yeah this didn't work and I had to abuse the written value of the interrupt handler to tell the pick code don't re-enable this one and this works but I cannot commit it directly this way. I have no idea how to do this. But when it's unmasked in the case of the keyboard the register to tell the device to stop interrupting was on a serpent bus. Right, but you could since you're using the GPIO registers to say I want an interrupt on this you can mask it as the GPIO and set that up. In here because it was interrupting on the main CPU line. Yeah, I feel my pain. Well I got past this one. Yeah, yeah and initially I was assuming it would so I was trying this and like what's going on? No it's fine, it's fine, it took me two months. That's right, that's another way to do it. Yes. Yeah, that's right. I can see how we do that. But it's please. Sorry? It's time to stop. Well there's like half an hour before the next stop. Yeah. Yeah, I think so. Because I have quite a bit, I'm going to go even faster. So yes, another thing I added recently is a speed locator to make sure that we no longer assume the lowest clock speed available. But because like on Linux, the I2C bus is running for the keypad, keypad part at least at 2 MHz, 200 KHz. We assume 100 KHz because it's the lowest safest setting there is. And which means when I type a key, I have to wait one second before I can type another one. Yeah, so we need a way to specify that each device is allowed to run faster. But different devices can go only as fast as they can. And so you need a way to tell this per device on a given bus. And yeah, the keypad driver is not complete yet. At least it was well enough for debugging and logging in and stuff. So there were minor issues. One of them is that I don't have a driver for charging the battery, so I have to charge it every now and then, otherwise it drains out. Some calls are not documented to not be allowed in interrupt context, like this one, which I got to know only yesterday. Otherwise, it was crashing just seconds after I was done booting. So I was like, yeah, no. Okay, what wrong? And of course, it was rebooting. So I had to film the device, frame by frame, and thankfully, it was giving me a full trace back before rebooting, so I could figure out, hey, do you know how to address this? Oh, check out this code. Oh, I need to ask you when there is a call for this. Awesome. I should modify the manual page. And I currently need to crash course on SPI because I'm writing the SPI bus driver, but I have issues. And I realized stuff only two days ago. I think you have to read as much as you transmit before you actually read. Yeah, it took me a while. I didn't know. I was reading one through the diagrams which say, electrically, what happens and how it's shifting stuff. I read the SPI driver for flash memory. And I heard that part of it by not reading what I wrote before I needed to read it. I wrote the cellless and the data. Yeah. In the case of OMAP, it says there is a register shift. I was like, where is the shift register? But actually, no, it's just that the register is the data that's online. And then it's shifted to the receive buffer before you can actually receive anything. So, yeah. And first I was reading the Marvel code and it was doing this, but I was like, this is so wrong. But actually, no, it was actually exactly what I had to do. Yeah, just didn't. So, yes, as I mentioned, I'm trying to get as much as possible in the main tree. I'm using Git for convenience to not spam people with commits that are half working. So it's on GitHub right now. I created a specific branch 10 days ago. This is not very easy to read. I'm sorry. But basically, the OMAP, the OMAP CPU support and main buses are mostly there. This is the companion chip. I got quite a few bits working. Some of it was already working. We first started working on this. Like the watchdog, LEDs, which I couldn't test. RTC clock, and so on. There is also USB on this chip and audio and another GPIO bus which I implemented but couldn't test. And, yeah, some more which I didn't even list here. It's massive. And all of this is over at I2C with the same mechanism that I explained for the keypad. So it's going to be implemented this way also. These are some generic sensors like the camera cover when you slide it open and close. The camera focus button, the audio jack, the lock button, and so on. The keypad slide, the source 1 GPIO when you open and close. So I implemented all of this and it's working for the most part. I2C devices. There is a battery monitoring device which I did implement. Same for the headphone amplifier, the audio. I implemented the accelerator but right now it's interrupting too often and I have to calibrate it. I implemented the beginning of the backlight support but it's not there yet. I have just a temperature meter. Great. Light sensor is also on there to handle the backlight. You know how much light is coming in and you have to give back for the user not to face this kind of situation with low contrast. The panel controller is on SPI. I don't support it yet. The touchscreen driver is on SPI. I almost have it working but I have this issue with the bus driver. It was tricky to know what was wrong between my touchscreen driver or my bus driver. It's a bit like the emulation versus hardware problem. You don't know which part is wrong and you have to just assume stuff and try them out. SPI is also on this chip so obviously it will require DMA to be fast and efficient because SPI is not so fast. Other devices which I have to figure out where they are and how I have the data sheets for most of these except for GPS, GSM and maybe some camera. So there is the LED torch for taking pictures. Both cameras front and back Bluetooth and so on which is still left to be done. However, right now I have the system booting multi-user and it starts X. We don't have the time to show it boot all the way through but I just took a video moments ago and I can show it to you right now during Eric's talk. Sorry Eric if I wasn't listening closely but I wanted to show this to you guys. This is booting multi-user here. It's just the last bit of the channel part. I think it's WSconce and it's focusing again a bit better now. Right there it's starting XTM. It's a bit slow. It has started poverty and a couple other services. Here initially I thought it was crashing but no you just have to wait longer. Longer. Longer. Oh it's black. Something is happening. What's going on? Longer. Oh, some gray and net-based logo on the right side. Closing close to victory and oops sorry. And so yes it's going to focus a bit more and we have XTM running with X console popping up and you can try to log in. The key map is wrong at that point but yeah. Next step. Okay so the touch screen doesn't work yet which is a bummer but hopefully soon. Quick watch on D4OS. The user learned part of it. This is the desktop running on a tablet device. The widget that I mentioned earlier with the telephony support because it also has a GSM chip inside so I can send SMS's and so on and say which is the operator and I was running because I took this during EuroBSG account in Poland and I'm based in Germany. Virtual keyboard. A bunch of applications available. This is when running simulated on a phone with a zoo which is nicely putting an extra skin around the screen which is running Z4 or XNAS with the right resolution and then you can test your user applications with a regular screen size and make it finger friendly and stuff. This should be big enough for my finger. And so on. This is an old screenshot. I improved quite a bit since then but you have icons on the desktop to emulate like the home screen and usually I use matchbox even if I have a few bugs with it and so on. This is D4OS on a real phone on the OpenMoco. Well I had performance issues so it looks ugly. It's no gradients, nothing. Just grey, white, black. But it was working as a proper phone even giving phone calls with full audio support and everything. It could even suspend, resume, spare battery and so on. But this was on Linux where a lot of work was already done. I have to do the same for NetBSD now. Booting NetBSD I just showed it. It goes all the way there. So the future. Get rid of these non-diplomented comments in my tables in the driver support slides. Get as much as possible inside NetBSD proper. Try to polish things for 7. This is going to be difficult. Maybe it's going to be much better than NetBSD 8 or whatever. Let's see how it goes. I'm going to of course keep working on D4OS at the same time. Try to support more devices including my regular phone the N9 which is pretty much the same hardware actually so that's kind of neat. And there is documentation on how to flash it. So when I maybe I'm going to just buy another one and it's still possible to acquire it on eBay. So yeah, thanks to all of you for listening. Thanks to these people in particular and companies for making this possible. And I hope we all learned something today. If not, there are lots of other talks after mine. And if you want to reach me feel free. LibroFist is really bad at handling styles as you can see. But yeah maybe I could select all of that. It's even worse. Yeah, LibroFist. Okay, let's cheat. Not huge. It should be big enough. Very important. And please, please, no. Okay. Yes. So that's it for me. And see you soon. Yeah. And people get to work on them when the hardware is on the fly. Because then they stop using it as the regular daily stuff. And that's what I did. Just with a lot of the the expertise in doing this sort of thing that you're developing and using and some of the public approach you gave you at the end. Have you managed to form any other relationships where you might be able to get stuff a little bit earlier in the development cycle? Not exactly. Because I have a day job. I would gladly do some consultancy work and work on this. I like my job. It's also like this. So it's kind of tricky. However, yes, I would like to have access to more devices earlier and to be able to work on this earlier. And this would be great, of course. If you're free to reach me, if there is anything. If you know of hardware where you have access to it where sufficient documentation is available already. Yeah, sure. I wanted to mention also that the first one to port NetBSD to a phone. I think on YouTube you can find videos of people putting NetBSD on some Windows CE devices. Running ARM also. HPCR and maybe some more. But of course it's also obsolete hardware. Yeah. I think older HPC devices also include NetBSD. Yeah, certainly. I have several of those devices in my garage. But they don't have GSM chips today. They don't have GSM chips. No, they don't. GSM is going to be another puzzle because there is no documentation, I guess, for the baseband. And it's going to be tricky to support telephony as well. But we could use soft phones over Wi-Fi. Which would be, yeah, already something. Have you worked at all of running an Android user on NetBSD kernel? I haven't. And I don't want to do this because right now what saves Android from my consideration is that it's GPL. And so they have to play by the rules. And if we begin to support Android on BSD, maybe they're going to switch to BSD. And then we will have no save in the matter anymore. No access to source code or anything like that. Yeah, I think the user-run part of Android is not in BPL. It's BSD license. And sometimes you can get the source of some kind of can. The kernel parts being part of Linux, sometimes you can and sometimes you can only in theory. And I don't think Android devices are trying to get the Linux source that I have in my hands. I get 3 year old and I have a bad experience with Android too because I was training in-out just to see how it goes on some device that was not running it originally, some Windows SE device. So I booted a community-based distribution which had ported it very nicely, everything worked perfect, including the Google account, which means Google has complete control over a phone that it didn't sell contribute to. It's not the operator. It's the hardware manufacturer. And when I wanted to download an application myself, faking the phone on the main Google portal, it installed it on the phone directly. So I was surprised and I checked what was going on because it couldn't be the first to possibly see this. And in Google I.O., Google said, okay, now you can manage your phone from the browser. And people were like, yeah, woohoo, but it's 1994 all over the place because you give control and everybody running Android basically gives control to this company even if they run a community-based distribution. It's really difficult. The FSF did it. Yeah. Anymore. It has to be a separate and supported. Yeah. But I really don't like the situation. I mean, if you're aware of it and you accept it for yourself, perfectly fine. But I do not for one thing and I think that the the way that it works is but I do not for one thing and I think many users do not know the possible consequences of running Android because this private company in the States has control over everything that's running on your phone. And that's a fact. So, yeah. That's why I'm doing all of this. Thanks.
 Okay, so let's go.  Thanks everyone for joining.  Hi, good morning.  Usually I don't like to speak on mornings,  but since I'm based in Germany,  I like to travel this way  because it makes the Saturday a worst day,  and I'm actually awake.  Which is good because  I spent most of last night  writing these slides.  I'm still heavily working on this.  This meaning I'm trying  to port net-psd  onto this phone.  I'm not the first guy to do this,  but first let's say  who I am.  So I'm Pierre Pocherie, as I mentioned,  I'm based in Germany.  I'm freelance. I've been working on  operating system development  as a hobby for many years now,  about 10 years, and I'm a  net-psd developer as of May last year,  so it's been a little more than a year now.  So  first I'm going to say why I'm doing this  because  there's a lot of history behind it,  lots of different reasons,  and I happen to have  the Nokia N900 here.  I got it a few years ago.  I'm going to explain how.  It's kind of a funny story.  I'm going to tell a bit about  the ARM architecture, because this phone  runs an ARM processor,  and net-psd was already running on ARM  before I started working on this.  I'm going to tell a bit about the net-psd  in particular.  Of course, this work  that I'm doing here is not exactly trivial,  so I faced a number of challenges,  and by the time I submitted  my talk and hadn't really  started with this work,  I was hoping I would be able to give a phone call  with this hardware. Unfortunately, it's not the case,  but I have still  quite a few things to say.  I'm going, of course, to mention  where I am right now with this work,  and what I want  to run on this phone, the Dufrawa  project, which is the result of my  work as a hobbyist,  about operating system  development, and I'm going to  speak a bit about how I see the future,  what I want to work on after this talk.  All right, but first,  a lot of things  happened for  in the last  13, 15 years.  So, a first friend gave me a Linux CD  back in 1999, when I was  still 18.  My computer was not  really happy with Linux, so I got a free-based  CD shipped from the US,  because at the time I didn't even have DSL at home,  I had only an old  PST and Modem.  Although  free-based CD was working good, I  sticked with Linux for a while, then I played with open-based  on some circuit hardware.  Then a friend of mine got a Zoros PDA.  It was a small device,  I have a picture after these few slides,  that was  embedded at a retractable screen,  which could pivot, and the device  could become a tablet.  In the meantime, I switched  my desktop and laptop environment to an  SD. I bought myself a Zoros PDA  as well. I tried open-based  on the Zoros PDA, it was working  very slow, but working at the time.  So then, my ex-boyfriend got invited  to a bar camp. I was playing with this Zoros  during her talk. One of the  bar camp attenders saw me doing this.  I began to work  after that on the Diffresd desktop.  I got some of it to work on the Zoros  on OpenBSD.  I attended the CCC  camp near Berlin, I was 2007,  I think.  I was doing my birthday, my ex-boyfriend offered me  an OpenMoco phone, which was an open  hardware phone. I ported  the Diffresd desktop to the OpenMoco phone,  so this is not the first phone I'm working on.  The bar camp attender  happened to be at the CCC camp too.  He was head of a  hosting company in France.  As part of his research and development  initiative, we began to sell  the OpenMco coffee runner.  We sold Europe-wide.  We created a linse distribution to support  it, which was Debian-based, because at the time  there was hardware, but none of  the software solutions were really  satisfying to us, and we had to support  it, so we decided to take  Debian and improve it. OpenMoco  was end of life after that.  Splitways with Versteck, who was  reselling this device. Another friend  gave me some Spark64 boxes.  I got a lot more involved with NetBSD doing  this, because I was trying to run my desktop  on Spark, and so I ported my  Diffresd desktop on Spark, on NetBSD.  Then Nokia invited me to join  a developer event, where they  gave me an N900, this  device here, which is not  exactly a phone, but can be used as a phone.  The bar  tender pointed me to a contest.  The contest was about creating  an open source  software-based tablet, so I  took my software again, adapted  it to the tablet environment.  I  co-won the contest this way.  I shared the prize with another guy who  was doing Android stuff.  Yet another friend  put in NetBSD on the N900,  and he's the reason why I'm here.  After giving a talk about the withapp  tablet, which is the one with which  I co-won this contest,  I promised to work on this phone  next. I applied to BSD Can,  and I had basically nothing working  at the time. I tested  Maple syrup for the first time in Canada two days ago,  and here I am in front of you.  I need some water.  How was the maple syrup?  Awesome. I love it.  I'm going to get a keg when I get back.  I'm going to go through the airport with this.  I'm going to have it in the airplane with me.  Share it with you.  Great.  I will make sure that I have that  with me on the plane, because I won't lose it.  That would be a shame.  Yeah.  It's funny. Usually there's a leaker over there,  and here maybe it's a local leaker.  Equivalent.  I'm sort of sugar addicted anyway.  Yeah, so this is the Zorus  PDA.  So I had been...  OpenBSD was ported on this, and I ported my software  on OpenBSD on this at the time.  A few years back. This is the OpenMoco  Free Runner.  It was developed by  an off-spin of  FIC, which was a Taiwanese  which is a Taiwanese manufacturer.  Usually they do mainboards  and consumer electronics  for auto companies,  and they had this research  group  started as a spin-off,  and OpenMoco was therefore  developed as an open hardware solution  in Roser and Linux.  Everything open-source, the hardware included.  You can still find it online  if you want, but it's a bit  outdated now, the hardware.  This is the WeTab.  It's not really great here on this slide,  black and black, but  I'm sorry I didn't bring it  this time.  You can watch my TouchonetBSD talk  which I gave at EuroBSDCon,  or I presented this  a bit longer.  This is D4OS, what is this? Just a logo.  I'm just teasing you now.  I'm going to show a bit more of its  new slides.  Alright, this is the 900,  which you can also see here in my hand.  It has quite a big screen.  Keyboard, which is great for debugging.  USB ports,  two cameras,  and it's the  it's the  one, two, three, four  device in this series, the N series of Nokia,  I mean the N series tablet  of Nokia, but the first one  to have a GSM chip.  It's based on Nomap, which is an ARM  socket system on a chip  integrated solution,  ARM based. It has a reasonably  fast processor, quite a bit of RAM  especially by the time for an updated platform.  It was released late 2009.  The touch screen is single touch,  but other than that, it's pretty modern.  Lots and lots of connectivity,  Bluetooth, GPS, GSM,  FM receiver, transmitter,  as I mentioned, it's a 3G.  And it ships with native Linux  already when it was released.  Memo  was based on  different GNU Linux. Here I use the pass because  Memo is pretty much dead, unfortunately.  So this is a hybrid tablet  with a very funny platform.  It's switched from DTK Plus  for user interface to Qt  with the 900.  Most components are open source though.  There is a good community around the project  which is still alive  even if Nokia gave up  supporting it.  I think now there is an independent  company  or group taking care of the project,  so it was migrated to a new platform,  but the Wiki still exists  and there is a lot of documentation and so on.  So it died  because of some debatable political decisions  at Nokia where they partnered  for a while with Intel. Intel had  Moblin, Nokia had Memo, it became  Migo, but Intel was doing its thing  and Nokia was doing its thing  and in the end  it didn't really turn out really well.  So this is the outcome of it.  The one and only Migo phone publicly  released and available.  And it was really Memo with some compatibility  layer to be able to claim it was Migo.  So really it's still Debian based  and so on.  Whereas Migo supposedly  supports only LPMs.  Which is kind of poor.  But it's dead anyway.  Now it's Tizen and something else.  But there is a new company  called Jola which was created by some  ex-Nokia employees  which is working on a new phone  and is continuing the Migo  development their own way.  So we can watch online there are a few presentations  on how it should look like  and I think they expect to launch  next month also in China.  But anyway, what's good for us now  is that there was lots of documentation  available and a working code for almost  everything. GPL but still  something to read in order to  try to understand how to get all of this  working. So it looks like this  when it was released.  So very well integrated  to-do lists, calendar,  it's connected to  exchange. So it was already  windows-oriented at the time.  Lots of applications, very  easy to customize and so on.  So now  let's get a little bit more  into details.  If you don't know much  about ARM, I believe you  mostly don't know about ARM.  But anyway, it looks very much like a regular  PC inside. So you get CPUs  and DDR RAM, some storage  space, there are some buses, it's  a PCI but it's sort of the same.  There is user input,  lots of interfaces, connectors,  3D acceleration for graphics,  video acceleration.  However, there are additional constraints.  It's a mobile device which means  it has to be autonomous. So there is a battery.  You have strong constraints  on voltage,  frequencies,  how long it's going to run if you  set the CPU a bit too much. Of course  the physical size is a constraint also  here, it has to fit your pocket.  However, nothing prevents running BSD  on it, except maybe in the future for  secure boot, which is the  new way to boot devices  coming up with UEFI  and so on.  Whereas on x86 secure boot  still allows you to boot whichever  system you want, you can disable it.  On ARM it's not the case.  So it's pretty much, now it's going to  be a completely closed platform  because all of the new devices shipping  with Windows 8, or most of them,  supposedly you cannot jailbreak them  and run your own OS.  I'm sure people will figure it out,  but it's getting more and more difficult  with this new hardware.  So I prefer not to invest in this  and work on my own shit.  So, very short introduction  to the ARM processor itself.  It's risk based.  There is now 64 bits version  but usually you will find it in so little bits  and in little Indian, although  it supports also big Indian.  The company ARM  doesn't manufacture any processor themselves.  They license the design  to bigger companies like Samsung  or TixxS Instruments  and so on.  There are lots of different generations.  This company has been around for many years.  Maybe sorry or something like that,  I don't remember.  And as a consequence, there are  as many different ARM platforms  as there are combinations of  processor design generations  and instances  of like  boards and chipsets.  So it's not really just  one coherent platform  or sort of coherent like X86.  You cannot run just any ARM code  on any ARM processor.  It's not many this way.  So it's a bit particular  and then about the OMAP solution in particular.  So it's  based around a general purpose ARM core  which is completed by  lots of different core processors and extension chips.  It was popularized in the open source world  by the Bigel Board  which  is based around the third generation  of the OMAP processor, 3530  and it's  luckily very similar to what's inside  the 9900.  It has a different name, 3430  but really it's the same chip inside.  It's just that the packaging is different  because I guess they had to  they needed a different version of their core  for smaller constraints, different physical  formats and so on.  So the Bigel Board looks like this.  You have the main processor here.  Lots of connectors  companionships here.  I guess one of them is the power companion  which actually has a lot more  connectors  because the OMAP processor doesn't do much in itself  in terms of  user input and so on.  It just exposes buses basically.  So yeah,  there is RAM and everything fits  in a small board which is  maybe 6 centimeters wide  where it's 3 inches, that's 7.50  or something like that.  7 centimeters.  So main TPU  has inter-uplines, like you would have  on x86. The buses  are not PCI or ISAR  whatever, they are I2C, SPI,  GPIO and so on.  GPIO in particular  means general purpose input-output  which means it's just a bunch of pins  and you can use them whatever  way you want. They can be input pins  or output pins and your input or output  data or you can abuse them  as interact pins where you just  listen to whatever is happening and the chips that  knows about this and you tell it to wake you up  when some event is  happening. Either when the pin  is low or when it's high  meaning 1 or 0 basically  or when it's changing state  which means then that it's  edge triggered. So level triggered  is when it's a given level, it wakes you up  low or high and edge triggered is when  it's going from low to high or high to low.  This is going to be very important  when developing this.  So you have after  the OMAP processor, a companion  processor typically interrupting inside  the OMAP CPU so it has a special  line, special connection to the  CPU on the PCB  so it's  however connected on a separate bus  and you have lots of additional processors  between each of the different functionalities  that you're going to require like Wi-Fi  or Bluetooth or you name it.  It's just  lots and lots of different processors  and typically they interrupt  via GPIO pins which means they are  connected to the main processor  over the GPIO bus.  Sorry if I'm very fast here  I have a lot to cover. Just tell me  if there is anything you want  to  emphasize on.  Just as a reminder,  this is the old NetBSD  which was also ARM based.  So it was just a regular toaster which was extended  with some embedded board  running NetBSD and  it was fully operational using  the NetBSD system.  Alright, so NetBSD  EVB ARM is the actual port that I'm using  for doing this. It means  evaluation board.  Typically companies like the SES instruments  and others  develop  typical designs  for people  to grasp the platform  and experiment and prototype  before shipping an actual product  and this is pretty much what the big old board is.  And this port  explicitly supports  aims at supporting as many  of such prototype boards as  possible. And JSON top  is the maintainer of this port.  Alright, so  if you look at how many kernel  configuration files are available  right now inside this port  you have quite a few boards which are supported.  Some of them are maybe  familiar to you like the panda board  or the raspberry pi  the Anandjord is  here.  You have the big old board, the big old  board exam, the plain big old board  and a bunch of others. They are not all  all map, of course. There are lots  of different designs from Samsung  from  multi-eye, the toaster is there  and so on.  So NetBSD  why is it a cool platform  and why is it found on so many  devices? It's because  it's clean, so it's portable and it's portable  so it has to be clean.  Which is  a nice way to  abstract the system  and it means there are  lots of constraints in the way  all of the drivers are organized  and the way the system is is organized  and what you have to deal with therefore when you  work on this.  So bus access is abstracted typically  you use the same interface to talk  on different buses.  The same APIs are used  as much as possible across different architectures  which means you can typically  only expose what's supported by all  of them. And so specificities  are kind of tricky to  to get by in some cases.  Especially if you want to write generic code.  This was a problem in my case.  So the device tree model in particular  you have a virtual root device  which is just a way on which  to attach the real physical  buses. Then devices  attach on buses. They have exactly one  parent node so it's really just like a tree.  And in turn these devices  may expose more buses  and have more other devices attaching  to them and so on.  That's what you see in the message when you boot  the system on iCleanlux which is just  a big soup. On NBSD  it's really telling you okay this  device attaches to which bus  going to this other device going to the root  node.  And with all of that devices  typically register  sorry on interrupt lines  and they handle them.  And that's pretty much all they do.  Interrupts.  It's a very important notion here.  Typically whatever happens  on a device there is an interrupt for it.  Typically when you touch the screen there's going to be  an interrupt telling the processor  okay there was an event, handle it now.  Interrupts are expensive  because they are  directly you can only have  as many as you have CPU cycles.  And they occur all the time  because whatever happens the clock  tick  watchdog and alarm  user interfacing  packets on the network it's all going to be interrupts.  So you have to handle them as fast as possible  with therefore as little  code as possible. And it's forbidden  to sleep and be lazy while handling an interrupt.  Because the longer you sleep  the more interrupts you lose. Because when you handle one  you cannot handle others.  So typically you just differ  or you set a flag or whatever  and you accuse some  job to be done  and then you're back to regular mode  and the scheduler is going to do your job.  So for this you have different mechanisms.  One of them is the work use  but then you have also software interrupts  or  bunch of other stuff.  I should have listed them here maybe but  next time.  So as a consequence  I had to write dozens of writers  because there are lots of different devices  especially on a smartphone  when you have to handle audio, USB, touch screen,  keyboard  all of the network interfaces and so on.  Of course this  represents a lot of different  interrupts. Not enough  I mean there are too many for the main  processor.  And as I mentioned  I mentioned separate buses. The interrupts  are on GPIO which is one  bus and devices are usually on I2C  or on SPI  and in different buses  and in NetBSD you can only attach  to one bus.  So it's really tricky  to address this model.  The bad news is  yes it's tricky. However  there are mechanisms  to address that which are actually  pretty good just that you know about them  when I started  and it took me a while.  So yes let's get on with it.  So let's prepare.  Let's make sure the NoCard  and Android boots on  a microSD card.  So typically what you do when you walk on this  you open the phone  like the Steers is a great tool  to do that because you have to be gentle  because you have to do it all the time.  So when it opens  you have the battery here and so on  you can remove it.  And the microSD slot is here  which is pretty good because you can remove the card  put it on your laptop  and test whatever you have.  It's however very slow  and it requires  some modifications to the phone in the first place.  You have to switch it to developer mode  with the regular firmware flashing tool.  I think the wiki page  for this disappeared or is no longer reachable  from the migration  of Memo from the Nokia platform to the new one.  But there is another page  called Memo Flasher which sort of covers it.  You have to run this  Flasher tool, check the flags  and be very careful there.  So it would be good to find a cache  for this old page and put it online again.  Basically you have to flash  the bootloader to enable multi-boot  so that it boots no longer just on flash  but on your card optionally.  And you have to set the phone  inside developer mode because otherwise  some watchdogs are not addressed  and the phone just reboots after like 10 seconds.  Which is a pain when you  don't have enough time to boot and see  whatever is happening and then the phone reboots.  Yeah.  So the alternative is to film it.  But yeah.  So can you develop any of this  or at least  have a model of the development  of your phone machine  and you have to do all of the hardware  for all of the stuff?  So the question is if there is some  emulation platform  a way to emulate the hardware  and test it on emulation, right?  There is  a special QMU fork  aimed at emulating the  bigger board which was also  extended a bit for the  900. However the code  is very difficult to compile outside of Linux.  I managed to do that  then I managed to emulate  a bigger board bootloader  and for this you had  to create a fake flash  file.  However for some reason it refused  my flash file  because the checksome was awesome.  And I followed some weird instructions  from a Chinese guy somewhere  on Google code whatever  because it was the only place where I found  this  really new available.  Typically other than that the only thing you can do  is take an existing Migo image  which is going to be like 4 gigs  and you have to start from there.  Or yeah for the flash it's a bit smaller  but I didn't want to start from  a complex system I wanted to start from scratch  and so it's really tricky.  You have to run Linux  or spend a lot of time compiling it  and then I  wasn't able to actually  get NetVisit to run on this.  Yeah.  There has been some  development in the last couple of months  that there is a  port of QMU that does  work better and will  lose some net net  that's right.  Yeah.  Not one map 3 yet.  But yes we're getting there.  So yes be very careful  and if you can use emulation.  However emulation is not always 100%  like the hardware.  So sometimes you have something working on emulation  and not on hardware or the other way around  and then it's another  challenge altogether to figure out  what is really right  and how you should address everything  so it's never  100% solution.  So if you want to boot  the 900 and microSD  you need to set up partitions like this.  Inside the MBR  you want your NetVisit partition  to be the first one.  The third one has to be a DOS  FAT on which you put a UIMH file  and the boot loader is going to load it  and start the kernel.  And then it's up to your kernel to find  whatever it has to boot.  So good news is we can use  FFS  and create it this way.  You can just untar the different sets.  Run makedev  and slashdev which is going to help  the booting faster.  The FSTab looks like this.  Then you set the RC.conf  to be configured.  You can even enable xdm here  and if things are  alright it's going to boot  x all the way through.  It needs to be very patient right now  but I guess this is also going to be worked on.  We know  already why some things  are very slow.  So yes, it's  slow. It's a tedious test procedure  that I already mentioned.  You have no network boots.  You have no serial line interface  on this phone.  Actually there is one but it's low voltage  and even if you use the regular consumer  USB  serial adapter's fallout voltage  it's still too high for this phone  and you're going to break it.  So we know what the serial  connections are  but they are a bit tricky to connect to  and I don't want to solder on my phone.  They are under the battery cover  and there are like 20 of them  and you have to pick the right ones.  I don't remember what the rest is.  Maybe JTAG, I'm not even sure.  So yes, another  tricky part is that initially I had no  keyboard support.  So I could not even go into the debugger  and type in stuff.  I had to  update the microsd card every time  and boot it again.  That's a very, very slow process.  On top of that, the documentation  is extensive which is good  but it means the  data sheet for the main processor is  over 3,000 pages.  You don't need to read all of this  if you want to instead what's going on.  You're going to have to read a lot and read it again  and again and again.  The companionship  for keyboard support is another  1,000 pages.  So the way I worked on this is  I really forced myself  to do one change at a time  and test every time and try to remember  write down, note inside the code  what was working, what wasn't  in combination with what  and then, yeah  not get stuck on one given bug  because sometimes you don't understand  enough of the platform to understand what's going on  and so if you lose hours on this  it's just lost.  Often you just switch to something else  and understand something about the first thing  while doing this other thing and you come back to the first one  test and go back and forth this way  at least it worked for me.  So anyway  the first step was to differentiate  the platform with the Bigelboard  because even if there are very  similar platforms  the Bigelboard has a serial line and you don't  and it doesn't have a screen and you do.  So the first thing was to  change the Bigelboard  initialization code  to enable the screen and disable the serial line  for the console. Otherwise  you just had a black screen which is useless.  So I have introduced  the Canon Option OMAP 34  30 for this  which is not  the cleanest way to do this  but for now it works because it's the only platform  that has this chipset  at the moment and we're going to have to find another  mechanism if we ever have more devices  this way.  So that's minor really.  Challenge 2  I mentioned GPIO  many sensors  just attach on GPIO and tell you  okay I'm a button  when I'm low it means I'm pressed  when I'm high it means I'm not pressed  released  and you just  they change states and you just  want to know when they change states and you report it.  Unfortunately it took me a while  to figure out that the OMAP GPIO  bus driver supported  edge interrupts but only  rising or falling. Low from  too high or high to low.  So I just had to add these two lines  to add support for this and then  I could not only see buttons being pushed  but also being released.  And it's also this way for many sensors  like when you insert  a node in your plug inside the jack here  it's also on GPIO  yes?  How do you distinguish between  interrupts and interrupts and what's data in that scenario?  It's hard coded  basically you know this  device is going to be on this GPIO pin  and you know  it's going to be interrupting  or that its data can be abused as interrupts  or you can tell okay I'm always going to  output data here or I'm always going to input  data here.  So in a way interrupts are just inputs  but you react automatically  on this input.  But what I mean is if you're sending  data where you've got open  serial writing  by definition  which means your signal is going high and low all the time  how do you distinguish  between data  of the signal going high and low  and an interrupt event with the signal going  higher and low?  I think the way it's done  you're not going to be the same open?  Yes.  So either your data is just one bit  in which case it  doesn't matter because just at the time when you need  the data you check if it's high or low  and then it's 0 or 1  or you're using multiple GPIO pins  in this case you can transfer a word at a time  and you have another pin  which is working as interrupts  which is telling you okay read now  read now, read now, read now  and then you can use pretty much what happens  in a regular bus.  Yeah I think generally just to clarify  the confusion and then  I may be unclear about this but  you can't usually use a single  GDI token for both at the same time  you set up as an interrupt  and then you know oh I'm going to be  an interrupt on that and support it  and I'm going to do the first line  of the slide and then we can  read the message.  Okay maybe this is confusing.  Yes so say you have a button  and you press it.  It's an input pin because when it's pressed  it's going to return 1 and when it's released  it's going to return 0 and you abuse it  as an interrupt. Really it's input  and you react when this input changes.  You tell the processor  okay monitor this pin  and wake me up when there is a change.  So when you're in some circumstances  your data and your interrupt are the same?  Yes that's right.  Yeah.  This isn't for your data  which is fast.  This is for user function buttons.  Yeah.  Slow enough that you can get your interrupt service  in time to read what the pin state is  so that you can know  whether it's up or down  the rest of the system.  However sometimes it gets really hairy  and people implement I2C  over GPIO which is  really really slow but in some cases you want this.  Yeah.  You don't have an I2C bus and you want to talk  to some I2C device because some devices  only come bundled this way  and so you have to do this.  We support this in the BSD by the way.  We have a driver for this.  Yes that's right.  But in my case  I need to handle I2C devices  which interrupts  which is  next challenge.  Now it gets interesting  because of course you can only attach to one bus  but then this I2C device  is going to tell you  okay I'm the keyboard here  and I want you to read me now  because the user just pressed the key  and yeah so how is this  happening?  Well  GPIO pins are mapped  as interrupts.  It's not specific to  ARM or as a whole.  It's only a few ARM  platforms which are implemented this way.  I don't know if it's just an NBSD  thing or some kind of official thing  for a given platform.  But typically on ARM  interrupts are integers.  You have the system ones which go from  like 0 to 31 or something like this  and then  you have your own convention  and you start virtual interrupts  from typically GPIO buses  on  starting on another number altogether.  So here  in our case we have the  OMAP GPIO bus driver  which is found on this internal  bus  at this address for accessing registers  and checking the status of the bus and everything.  It takes this much  amount of memory to address  the registers  and it's going to interrupt starting  at 96 and this one  has 32 pins. So from 96  to 96 plus 31  you have  virtual interrupts and  you really will catch interrupts coming from GPIO  while hooking the same way as you would  with the main CPU.  So this is really practical  and it means you can  handle interrupts from different buses  using GPIO lines  and it's transparent because it's just  a number with the same interface.  You establish the interrupt, you register it  and  then you can handle it.  So there is generic code in NBSD  for this which is called  PIC code.  I don't know why I guess it's very similar to  what microcontrollers do.  Yeah, okay.  Programmer will interrupt the controller.  That makes sense.  Alright, so this way you can easily  handle interrupts  while having a device on the bus which typically doesn't.  But in practice this breaks portability  because it means in  order to see an SPI code  you will try to hook interrupts.  But these devices may exist  on different platforms where interrupts are not integers.  There are something else.  Or there are no interrupts available for these devices  in the first place.  So it's typically machine dependent.  This code is different  on each and every architecture.  Or you cannot assume it's going to be the same.  So  I proposed a patch at some point  adding an interrupt locator to these buses  but it was rejected.  And this was the right decision  because it's just not the right way  to handle this.  It's not portable.  So I created my own branch called  Corbin900  where I have committed  this version of the code  that I wrote.  And inside the main tree I committed  stuff with hardcoded values because there was no way  I could obtain these values from the  kernel configuration file  and there was no way of doing things.  In Linux it's well hardcoded  inside the code also.  Inside the code specific  to each and every different board.  So you don't have a single file where you can just tweak things  and have a working kernel directly.  You need specific code  for each and every one of the  platforms, young platforms.  All right.  So for the keypad in particular  it was very, very tricky  because the keypad is on  the companion ship.  The companion ship is on I2C.  It interrupts on the main CPU  because it's a special device which is  located on the main CPU.  Talking to the I2C  bus requires sleeping because  you send data and you wait for the answer.  But you're not allowed to sleep  in interrupt contexts.  So typically you just  want to defer the hand-rock.  You tell the scheduler to wake you up  when it's available  and you just hold the interrupt.  But the interrupt is not handled in the first place  which means it's just coming back to you  repeatedly and the scheduler  is never giving you the chance  to address it.  Which means you need to disable the interrupt  while you handle it and re-enable it again.  And so far in  NBSD for ARM at least  it was impossible to do this.  It was assumed that devices would just  register an interrupt  and never disable it. Just handle them all the time.  And in this case it's not possible.  So I've implemented this.  I had to modify the PIC code  to allow for this.  In a way that's affecting  much more hardware than just this one.  So I couldn't commit it directly.  I have to check all of the other drivers  to see if they  return the value that I expect or not.  Did I mention it here? Yes.  So typically  what in practice the compendium chip  it gets even worse.  It's connected to five different addresses  on two different I2C buses.  Meaning  the keypad registers  are reachable on one given address  not on the others.  But the interrupt  handling address is on a  separate place.  So what I do is  my main interrupt handler  is differing a first handler  returning 0  to abuse whatever was done  before and telling disabled interrupts  it's not handled yet.  This first handler uses a global  handler to wake  the keyboard driver at this other address  and it should use  another handler again  at lower priority.  So this intermediate  handler reports the key pressed  by accessing the bus at the right address  and then the other handler  that's running at lower priority, very important  re-enables the interrupt  because otherwise you don't get your key pressed  and you lose it  and you get back to step one.  And yeah, this took me a while  to figure out  with lots of  booting and black screens  because this code happens before the  initialization of the frame buffer.  And if it keeps interrupting  all the time it never goes  further and you just wait.  Is it going to pop up again?  Please.  Do you ever want the  reason you're not the solder serial  for an undercurrent?  Well, I figured it out pretty quickly  and I found another way.  I was abusing other interrupts  so I wrote a specific driver  for just differing this work  and waking up the other driver  to do all of this  initialization stuff.  Once the frame buffer was started  so typically I was booting  an interrupt for the touch screen  and I was just pressing on the screen  and then my keyboard code was starting  and I saw how it crashed.  And then I was asking on IOC  how can I solve this  and thankfully I got an answer  usually pretty fast.  Thanks guys.  So are you actually removing the interrupt handler  for the other stuff that's handling  or are you just masking them in the right way?  So what the pick code does  is it keeps a list  and then it  masks it again for the next time  which means if you  disable the interrupt  using a separate code that I added  during interrupt context  it's going to be re-enabled anyway  because after you disable the interrupt  this  pick code is listing whatever you did  and then it's enabling interrupts again.  So it means I had to really patch  deep down the pick code for this  because even if I was adding code  to disable and tell the processor  to stop masking it  I don't even remember which one is mask  or unmask  you tell the processor to stop  waking you up when there is an interrupt  but  when the pick code was done handling every interrupt  it was just re-enabling  all of the ones it had just handled.  So yeah this didn't work and I had to abuse  the written value of the interrupt  handler to tell  the pick code don't re-enable  this one  and this works  but I cannot commit it directly this way.  I have no idea how to do this.  But when it's  unmasked  in the case of the keyboard  the register to tell the device  to stop interrupting was on a serpent bus.  Right, but you could  since you're using the GPIO registers  to say I want an interrupt on this  you can mask it as the GPIO  and set that up.  In here because it was interrupting  on the main CPU line.  Yeah, I feel my pain.  Well I got past this one.  Yeah, yeah  and initially I was assuming it would  so I was trying this and like  what's going on?  No it's fine, it's fine, it took me two months.  That's right, that's another way to do it.  Yes.  Yeah, that's right.  I can see how we do that.  But it's  please.  Sorry?  It's time to stop.  Well there's like half an hour before the next stop.  Yeah.  Yeah, I think so.  Because I have quite a bit,  I'm going to go even faster.  So yes, another thing I  added recently is a speed locator  to make sure that  we no longer assume the lowest  clock speed available.  But because  like on Linux, the  I2C bus is running for  the keypad,  keypad part at least at 2 MHz,  200 KHz.  We assume 100 KHz  because it's the lowest  safest setting there is.  And which means when I type a key,  I have to wait one second before I can type another one.  Yeah, so we need  a way to specify that  each device is allowed to run  faster. But  different devices can go  only as fast as they can.  And so you need a way to  tell this per device on a given bus.  And yeah, the keypad  driver is not complete yet.  At least it was well enough for debugging  and logging in and stuff.  So there were  minor issues. One of them is that  I don't have a driver for charging the battery,  so I have to charge it every now and then,  otherwise it drains out.  Some calls are not documented to not  be allowed  in interrupt context, like this one,  which I got to know only yesterday.  Otherwise, it was crashing  just seconds after I was done booting.  So I was like, yeah, no.  Okay, what wrong?  And of course, it was rebooting.  So I had to film the device, frame by  frame, and  thankfully, it was giving me a full trace back  before rebooting, so I could figure out,  hey, do you know how to address this? Oh, check out this  code. Oh, I need to ask you when there  is a call for this. Awesome.  I should modify the manual page.  And I currently need to crash  course on SPI  because I'm writing the SPI bus  driver, but I have issues.  And I realized stuff only two days ago.  I think you have to read as much as you transmit  before you actually read.  Yeah, it took me a while.  I didn't know. I was reading one  through the diagrams which say,  electrically, what happens and how it's shifting stuff.  I read the SPI driver  for flash memory.  And I heard that part of it by not reading  what I wrote before I needed to  read it. I wrote  the cellless and  the  data.  Yeah.  In the case of OMAP, it says  there is a register shift.  I was like, where is the shift register?  But actually, no, it's just that the register  is the data that's online.  And then it's shifted to the  receive buffer before you can  actually receive anything.  So, yeah.  And first I was reading the Marvel code  and it was doing this, but I was like, this is so wrong.  But actually, no, it was actually  exactly what I had to do.  Yeah, just didn't.  So, yes, as I mentioned, I'm trying to get as much  as possible in the main  tree. I'm using Git for  convenience to not spam  people with commits that are half working.  So it's on GitHub right now.  I created a specific branch  10 days ago.  This is  not very easy to read.  I'm sorry. But basically,  the OMAP, the OMAP CPU support  and main buses are mostly there.  This is  the companion chip.  I got quite a few bits working.  Some of it was already working.  We first started working on this.  Like the watchdog, LEDs,  which I couldn't test.  RTC clock, and so on.  There is also USB on this chip  and audio and another GPIO bus  which I implemented but couldn't test.  And, yeah, some more which I  didn't even list here. It's massive.  And all of this is over at I2C  with the same mechanism that I explained for the  keypad. So it's going to  be implemented this way also.  These are some generic sensors  like the camera cover when you  slide it open and  close.  The camera focus button,  the audio jack, the lock button, and so on.  The keypad slide, the source 1 GPIO  when you open and close. So I  implemented all of this and it's working for the most  part. I2C devices.  There is a battery monitoring device  which I did implement.  Same for the headphone amplifier, the audio.  I implemented the accelerator  but right now it's interrupting too often  and I have to calibrate it.  I implemented  the beginning of the backlight support  but it's not there yet.  I have just a temperature meter.  Great.  Light sensor is also on there to handle  the backlight.  You know how much light is coming in  and you have to give back for the user  not to face this kind of situation  with low contrast.  The panel  controller is on SPI.  I don't support it yet. The touchscreen driver  is on SPI. I almost  have it working but I have this issue with the bus driver.  It was tricky to know what was wrong  between my touchscreen driver or my bus  driver. It's a bit like the emulation  versus hardware problem. You don't know which part  is wrong and you have to just assume stuff  and try them out.  SPI is also on this chip so obviously  it will require DMA  to be fast and efficient because SPI  is not so fast.  Other devices  which I have to figure out where they are  and how  I have the data sheets for most of these except  for GPS, GSM  and maybe some camera.  So there is the LED torch  for taking pictures.  Both cameras front and back  Bluetooth and so on which is still left to  be done.  However, right now I have the system booting  multi-user and it starts X.  We don't have the time to  show it boot all the way through but  I just took a video  moments ago and I can show it to you  right now  during Eric's talk.  Sorry Eric if I wasn't listening  closely but I wanted to show this to you guys.  This is  booting multi-user here.  It's just the last bit of the channel part.  I think it's WSconce  and it's focusing again  a bit better now.  Right there it's starting XTM.  It's a bit slow. It has started poverty  and a couple other  services.  Here initially I thought it was crashing  but no you just have to wait longer.  Longer.  Longer. Oh it's black.  Something is happening.  What's going on? Longer.  Oh, some gray  and net-based logo on the right side.  Closing close to victory  and oops sorry.  And so yes it's going to  focus a bit more and we have  XTM running with X console popping up  and you can try to log in.  The key map is wrong at that point  but yeah.  Next step.  Okay so the touch screen  doesn't work yet which is a bummer  but hopefully soon.  Quick watch on D4OS.  The user  learned part of it.  This is the desktop running on a tablet device.  The widget that I mentioned earlier  with the telephony support  because it also has a GSM chip inside  so I can send SMS's and so on  and say which is the  operator and I was running because  I took this during EuroBSG account in Poland  and I'm based in Germany.  Virtual keyboard.  A bunch of applications available.  This is when running simulated  on a phone with  a zoo which is nicely  putting an extra skin around  the screen which is  running Z4 or XNAS  with the right resolution  and then you can test your user  applications with a regular screen size  and make it finger friendly  and stuff. This should be big enough  for my finger. And so on.  This is an old screenshot.  I improved quite a bit since then  but you have icons on the desktop  to emulate like the home screen  and usually I use matchbox even if I have  a few bugs with it and so on.  This is D4OS on a real phone  on the OpenMoco. Well I had performance  issues so it looks ugly.  It's no gradients, nothing.  Just grey,  white, black.  But it was  working as a proper phone even giving phone calls  with full audio support  and everything.  It could even suspend, resume,  spare battery and so on. But this was on Linux  where a lot of work  was already done.  I have to do the same for NetBSD now.  Booting NetBSD  I just showed it.  It goes all the way  there.  So the future. Get rid of these  non-diplomented  comments in my tables  in the driver support slides.  Get as much as possible  inside NetBSD proper.  Try to polish things  for 7.  This is going to be difficult.  Maybe it's going to be much  better than NetBSD 8  or whatever.  Let's see how it goes.  I'm going to of course keep working on D4OS  at the same time.  Try to support more devices  including my regular phone  the N9 which is pretty much the same hardware  actually so that's kind of neat.  And there is documentation on how to flash it.  So  when I  maybe I'm going to just buy another one  and it's still possible to acquire it  on eBay.  So yeah, thanks to  all of you for listening.  Thanks to these people in particular  and companies for making this possible.  And I hope we all learned something today.  If not, there are lots of other talks  after mine.  And if you want to reach me feel free.  LibroFist is really bad  at handling styles  as you can see.  But yeah  maybe I could select all of that.  It's even worse.  Yeah, LibroFist.  Okay, let's cheat.  Not huge.  It should be big enough.  Very important.  And please, please, no.  Okay.  Yes.  So that's it for me.  And see you soon.  Yeah. And people get to work on them  when the hardware is on the fly.  Because then they stop using it as the regular daily stuff.  And that's what I did.  Just with a lot of the  the expertise  in doing this sort of thing  that you're developing and using  and some of the public approach  you gave you at the end.  Have you managed to form  any other relationships  where you might be able to get  stuff a little bit earlier  in the development cycle?  Not exactly.  Because I have a day job.  I would gladly do some  consultancy work and work on this.  I  like my job.  It's also like this.  So it's kind of tricky.  However, yes, I would like  to have access to more devices earlier  and to be able to work on this  earlier. And this would be great, of course.  If you're free to reach me, if there is anything.  If you know of hardware where you have access to it  where sufficient documentation is available  already.  Yeah, sure.  I wanted to mention also  that the first one to port NetBSD to a phone.  I think on YouTube you can find  videos of people putting NetBSD  on some Windows CE devices.  Running ARM also.  HPCR and maybe some more.  But of course it's also  obsolete hardware.  Yeah.  I think older HPC devices also  include NetBSD.  Yeah, certainly.  I have several of those devices in my garage.  But they don't have GSM chips today.  They don't have GSM chips.  No, they don't.  GSM is going to be another  puzzle because there is no documentation, I guess,  for the baseband.  And it's going to be tricky to support telephony  as well.  But we could use soft phones  over Wi-Fi.  Which would be, yeah, already something.  Have you worked at all  of running an Android user  on NetBSD kernel?  I haven't.  And I don't want to do this  because right now what saves Android  from my consideration is that it's  GPL. And so they have to  play by the rules.  And if we begin to support  Android on BSD, maybe they're going to switch to BSD.  And then we will have no save  in the matter anymore. No access to source code  or anything like that.  Yeah, I think the user-run part  of Android is not in BPL.  It's BSD license.  And sometimes you can get the source of some kind of can.  The kernel parts being part of Linux,  sometimes you can  and sometimes you can only in theory.  And I don't think  Android devices are  trying to get the Linux source that  I have in my hands.  I get 3 year old  and I have a bad experience with Android  too because I was training  in-out just to see how it goes  on some  device that was not running it originally,  some Windows SE device.  So I booted a community-based distribution  which had ported it  very nicely, everything worked perfect,  including the Google account,  which means Google has complete control  over a phone that it didn't sell  contribute to.  It's not the operator.  It's the hardware manufacturer.  And when I wanted to  download an application myself,  faking the phone on the main Google portal,  it installed it on the phone directly.  So I was surprised  and I checked what was going on because it couldn't be  the first to possibly see this.  And in Google I.O., Google said,  okay, now you can manage your phone from the browser.  And people were like, yeah, woohoo, but it's  1994 all over the place because  you give control and everybody running Android  basically gives control to this company  even if they run a community-based distribution.  It's really difficult.  The FSF did it.  Yeah.  Anymore.  It has to be a separate  and supported.  Yeah.  But I really don't like the situation.  I mean, if you're aware of it  and you accept it for yourself, perfectly fine.  But I do not for one thing  and I think that the  the way that it works is  but I do not for one thing  and I think many users do not know  the possible consequences of running Android  because this private company in the States  has control over everything that's running on your phone.  And that's a fact.  So,  yeah.  That's why I'm doing all of this.  Thanks.
Call_your_NetBSD_0_827.png Call_your_NetBSD_828_1307.png Call_your_NetBSD_1308_3215.png Call_your_NetBSD_3216_4679.png Call_your_NetBSD_4680_5555.png Call_your_NetBSD_5556_7307.png Call_your_NetBSD_7308_8447.png Call_your_NetBSD_8448_9311.png Call_your_NetBSD_9312_10235.png Call_your_NetBSD_10236_10643.png Call_your_NetBSD_10644_10883.png Call_your_NetBSD_10884_11207.png Call_your_NetBSD_11208_12347.png Call_your_NetBSD_12348_15203.png Call_your_NetBSD_15204_15659.png Call_your_NetBSD_15660_17939.png Call_your_NetBSD_17940_19427.png Call_your_NetBSD_19428_20495.png Call_your_NetBSD_20496_21383.png Call_your_NetBSD_21384_23723.png Call_your_NetBSD_23724_24407.png Call_your_NetBSD_24408_25355.png Call_your_NetBSD_25356_26255.png Call_your_NetBSD_26256_28775.png Call_your_NetBSD_28776_30587.png Call_your_NetBSD_30588_32051.png Call_your_NetBSD_32052_32171.png Call_your_NetBSD_32172_37355.png Call_your_NetBSD_37356_39383.png Call_your_NetBSD_39384_42467.png Call_your_NetBSD_42468_43655.png Call_your_NetBSD_43656_49511.png Call_your_NetBSD_49512_52835.png Call_your_NetBSD_52836_55067.png Call_your_NetBSD_55068_57155.png Call_your_NetBSD_57156_65411.png Call_your_NetBSD_65412_66887.png Call_your_NetBSD_66888_69779.png Call_your_NetBSD_69780_70379.png Call_your_NetBSD_70380_70655.png Call_your_NetBSD_70656_71243.png Call_your_NetBSD_71244_71927.png Call_your_NetBSD_71928_73571.png Call_your_NetBSD_73572_74087.png Call_your_NetBSD_74088_74315.png Call_your_NetBSD_74316_74387.png Call_your_NetBSD_74388_74579.png Call_your_NetBSD_74580_74651.png Call_your_NetBSD_74652_74723.png Call_your_NetBSD_74724_74771.png Call_your_NetBSD_74772_74819.png Call_your_NetBSD_74820_74903.png Call_your_NetBSD_74904_75011.png Call_your_NetBSD_75012_75059.png Call_your_NetBSD_75060_75107.png Call_your_NetBSD_75108_75155.png Call_your_NetBSD_75156_75203.png Call_your_NetBSD_75204_75251.png Call_your_NetBSD_75252_75299.png Call_your_NetBSD_75300_75371.png Call_your_NetBSD_75372_75419.png Call_your_NetBSD_75420_75467.png Call_your_NetBSD_75468_75515.png Call_your_NetBSD_75516_75563.png Call_your_NetBSD_75564_75611.png Call_your_NetBSD_75612_75659.png Call_your_NetBSD_75660_75707.png Call_your_NetBSD_75708_75755.png Call_your_NetBSD_75756_75803.png Call_your_NetBSD_75804_75851.png Call_your_NetBSD_75852_75899.png Call_your_NetBSD_75900_75983.png Call_your_NetBSD_75984_76067.png Call_your_NetBSD_76068_76115.png Call_your_NetBSD_76116_76835.png Call_your_NetBSD_76836_77711.png Call_your_NetBSD_77712_78467.png Call_your_NetBSD_78468_78575.png Call_your_NetBSD_78576_78647.png Call_your_NetBSD_78648_79931.png Call_your_NetBSD_79932_80171.png Call_your_NetBSD_80172_80555.png Call_your_NetBSD_80556_80735.png Call_your_NetBSD_80736_80831.png Call_your_NetBSD_80832_80963.png Call_your_NetBSD_80964_88597.png