Hi, my name is Chris and this is my colleague, Iago. We're from a company based in Berlin, we do open source consulting and among other things,

we are working right now with a client who has us basically running three androids on one Galaxy S3 with one gig of RAM. I think there's been a couple talks at this FOSM about running multiple androids that's mostly based on Zen, I think Zen is doing work.

I was watching one of the videos, not from this FOSM but from another event and they were talking about how they were having memory constraints on the Nexus 10 that they were working on with two gigs of RAM, so that's always kind of amusing for us with the constraints

that we have. This talk is actually as much for us as it is for anybody else, because if you have ideas or anything, please stop us and give feedback or the questions will be very much welcome and hopefully after the talk we can talk to you also about some maybe

improvements that you have. Okay, so the first question is, what exactly is low RAM and who defines this in recent, I think since about, I think sandwich, about 512 gigs. If you're at this level or you're below this, then you're probably going to have

to look at some of the things we're going to be showing to improve performance or just to modify it to your system so you get good performance or good advice. Yeah, so when would you really find yourself in this situation?

There are actually several reasons why. You have no choice, maybe you have a client, this is similar to the situation we're in, and basically you have no control over the hardware you have, the memory or anything like that, and so you're just told to do it and so you're kind of behind it.

You see that you do what you can. You could be one of these people who runs devices that are more than about two years old, and then you could be one of these rare people who actually likes to put an updated Android on these devices. I don't really know any of these people, but they do seem to exist.

And then I think some of the more interesting things, you have Android coming into the embedded space where a typical or a traditional embedded Linux was found, and a lot of people are seeing more and more of that because there are some features there that are quite attractive and you'll be just getting it on pretty quickly.

And then you have what I just talked about, the virtualized Android. Actually I should mention a little bit, we work for a company called Trust4, and they're working on this high-security Android, and so we have basically two user-facing Androids, and then we have a third Android that's pretty much

everything taken out of it, runs on very little resources. But it helps with hardware, so we have basically a layer where the user-facing Androids, they have no direct contact to the hardware. And we run this on a microkernel hypervisor, it's not, it comes in,

and actually I think the main developer for that is actually, I think they have a talk on the microkernel tracker. Okay, so let's move on and actually look at the layer where we actually do things. Now the first layer is the one that's most, it's the one that's most accessible to everybody.

But we can't really ignore this because even if you're creating the device, you have to make decisions on what apps, you know, for a browser for example, you have the unmaintained browser that's there now, or you can choose something like Firefox, another Google source browser, and if you look at these you will see that they do things, one does things better than the other as far as memory management,

and we'll actually talk about why that is. Okay, the next one is the dolphin Liam, as everybody pretty much probably knows. Android uses their own Liam for Dalvik, and this was for several reasons, licensing, performance, et cetera.

And we should also point out that they have a new input part, and so this actually might eventually be deprecated and not used, but for now it's still to be followed. And activity manager, now this is the integral part of Android, and it actually plays a major role in memory management, and we'll look at just the memory management portion of this a little bit.

Alright, and we have the Linux kernel, this is usually the bottom layer, if you're like us, that's your kernel version, so you have to have one underneath to worry about. But yeah, we'll look at a couple ways that the Linux kernel, there's some additions from Android, but there's also some upstream,

there's a lot of Android benefits from what's in the Linux kernel as it is. Okay, I'm going to start with the apps, and then we'll go over to the ER and go through with it all. Okay, so the apps, it's important for everybody actually, all the apps, to manage their memory properly.

This doesn't happen all the time, a lot of it rarely happens, but if your app manages the memory well, then the whole system will potentially be more stable. And so it's a good idea to do that. And we're not going to look at all these ways apps can individually manage their memory,

but we're going to look at how the system tells the app what kind of pressure the system is under so that it can respond to that, and we're just going to look at this very briefly. So yeah, Google says you should implement home trim memory

to informally release memory based on the current system constraints. Now home trim memory, it takes up the router integer, and this is actually a trim load. And this will tell you basically how much pressure the system is under. You have two basic categories, you have your running apps,

and then you have your cache. The cache apps are basically the ones in the background, and they're already on the LRU list to be killed. And so this is roughly the rows are basically for the urgency, and so the margin and the background for the cache.

You can probably start doing something here, and you probably should, but really, if you get down and throw it when you're complete, then you really, really need to do something. So yeah, basically, memory complete means you're all here in the background,

and if you don't do something very quickly, you will be completely lost. Oh yeah, there was the seventh one, and this is on a trim memory UI hinge, and this is basically when you're out and it goes into the background, and there's no visible UI. You can do things like freeing your views,

and freeing your business, and things like that. Okay, so I'm going to hand over to Diago now for the... Diago? Oh yeah, sorry. It wasn't my fault. And this is trim on trim memory that started in Icebreed Town, and so you still need to implement the on-load memory for older devices,

and that's basically what we're going to do with trim memory complete. Okay, so I'm going to hand it over now. Okay, so Dalvik VM, as Chris said before, is the Java virtual machine that Android uses. So we're going to first look a bit at how Android

already does some things to keep the memory footprint down. First of all, Dalvik VM is a register-rate virtual machine, whereas the regular Java machine is a stack-based. So each one has its fans, there's a bit of discussion,

but in the register-based virtual machine, each instruction is more dense in the sense that you have to put two registers to work with, whereas in the stack you just push or pop one register. It also makes the code a bit larger.

They say it's more performant, so that's what they use. And the important feature of this is that it doesn't use the Java class files and JARs. It uses a format called DEX, and this is a format made for...

It's a very compact format. So the Java classes have a lot of duplication. For instance, if you have an interface, an implementable interface, and a user-friendly interface, it records the name three times in the Java class file.

So yeah, DEX addresses that and makes some more presentations about that. The gain of space is very high, so a DEX file is roughly the same size as a JAR file compressed,

but the DEX is uncompressed, and that is important because DEX files can be mapped directly to the memory, so the kernel can keep the pages from the file if it needs to be. Also, you might have seen, well, when you're playing Android,

you see the style optimizing the apps. This is DEXsoft. This program converts DEX files to optimized DEX files or objects, and it verifies that the file doesn't do anything illegal, and it also does some optimizations like through empty methods and stuff like that.

Another way that Android saves memory is with the Cypher process, which handles its form of new processes. So at root, Cypher loads the kernel memories that most apps use, and then it forks the processes, so every process formed by Cypher can share everything,

and that's a big memory gain. And, yeah, lastly, in Android 2.2, they introduced the adjustment timing power, and, yeah, they were saying that, at first, you can reach a twofold improvement, but in the new KitKat guidelines for low-memory devices,

they say that for low-memory devices, we should disable it because it takes memory, this JIT cache. Yeah, I think I skipped all the points, but you get the idea. So, we're probably committed with this output.

It's the atomic VM in the log jet, and it's telling us what is garbage collecting. So there's four kinds of garbage collectors. Here you can only see three, because the last one is called GC-before-over,

and if you get to that point, you are going to run out of memory, so you don't want that. So the rest are GC-explicit. When you call explicit garbage collector, you can do that in your app, or the framework can do that.

For example, when a binder connection gets dropped, it runs a garbage collector. Then there's GC-concord, which is the normal garbage collection, and this runs when the amount of free memory goes below a certain threshold.

We'll see a bit more in the next slide about this. And then there's GC-fraud, which happens when you're trying to allocate an object and the heap doesn't have enough space, so it has to do a garbage collection, and then it can grow up the heap to make space for that object.

And how can you tune the heap so that you can put it right away for longer devices? Well, there's six properties you can set from the property of a write and pick up time. These are heap start size,

and this is the size that heap has on the app. And then there's these two that are sometimes a bit confusing. heap-growth-limit is the limit that the heap has for regular apps, whereas heap-size is the limit that the heap has when you declare a large heap property

in the run rate manifest in your app. And that's not very good, because if the heap is larger, your apps will not perform slower, but some apps might increase heap size. The next one is heap-target utilization, which is what the garbage collection routine uses

for knowing when to do garbage collection. It's clipped to 0.8, so if you put more, it will be 0.8 anyways. The last two ones, heap-me-heap and heap-mux-free, heap-mux-free is the minimum amount of memory that has to be free,

so if you go below that, it will grow the heap automatically, and mux-free is the opposite. Now I'm going to talk about a bit chit, and why Google asks for disabled heap.

For the first number of devices, we recommend chit to be disabled entirely. Why is that? Because when the chit translates back to negative code, it needs to store it somewhere, so Android has a cache for the negative code in memory, and if they say that you disabled it,

you can save up 1.5 megabytes per process. Anyway, you need to know, you need to test if it's really worth it, the performance, the loose performance for the memory, and it's fine because in our case,

in our virtualized device, we found that we have increased memory, but also increased performance, but that might be explained because our system has a very low volume, and we need to investigate more of that. So I'm going to hand over to Chris again,

and he will talk to you about a bit. So if I want to go back to the last point I was thinking about the trimming, we had found, and just to give you an example of apps that basically do it well, apps that don't maybe do it so well, so people probably know

that there's a default browser in Android, and now it gets unmaintained, basically because of the swimming program for Android, but we found, when we were looking for, we found that the problem was one of our biggest problems as far as memory users, and it wasn't really reacting to the memory pressure well,

and we found that, for example, Firefox on Android was actually doing at least something, and it was, basically, it improved our stability quite a bit, so we're eventually going to be able to do that, which is quite nice. Okay, sorry, I'm on the first slide, yeah. Okay, so Activity Manager has,

is pretty much a central part of Android. It does a lot of things. We're going to basically be looking at the, very briefly, at the way that it orders your applications by priority, and then it does use this information that it's maintaining to basically tell the low memory killer

which apps have which priority, etc. Okay, so, yeah. So, Activity Manager, it's always maintaining a list of the applications and the importance to the user

or to the system. There are, you know, the most important systems, system apps, and then there are the foreground apps, which have, of course, library, and then you have things like what are called acceptable apps that are running, processes that are running.

And these are things like, if you have a music player, it might not be in the foreground, but it's important that it doesn't crash because a user probably doesn't want their listening enjoyment to be interrupted. And if you can see here, well, I should have probably put it, this is actually, all these declarations are in the process list.java

and the Activity Manager code. And so, what you see here, it's similar in nice value, the largest number is the least important, and then the smallest number is the most important. Now, these correspond to values that the Linux O takes

for their O to adjust the value. And we can see here at the top, you see here, I mean take that, I actually changed the cache, but I guess, yeah, this thing's described a little better. And you see at the bottom, it goes down to negative 16, these are system, or system categories.

There is actually another value that's, if you do negative 17, that will basically say remove it from, remove it from consideration of killing because, yeah, and so it's taking away from this management system, basically. And you may need to do that for apps that, for processes that really need to stay alive.

Okay, so, it uses the information, like I said, to pass it to the low memory dealer. This is one of the, this is kind of a prelude to the to the kernel changes we were going to talk about a little bit. But the important part about it now is this is the Activity Manager and the low memory dealer kind of work together

because it, the Activity Manager basically feeds the information to the low memory dealer with its SysFS interface. yeah, so it has, it basically tries to preemptio. Android never wants to get the case where it's really out of memory.

And so this kind of, this low memory dealer just, instead of out of memory, it's low memory so that you can avoid actually reaching the level where you're at and have to kill the system. Add some things. Okay, so, this is actually the interface we have. And if you do

a cap on these files, you will see these values. Now these correspond directly with the values that we saw that were defined before. The first layer, although I think if you print this out on a KitKat device, you will actually see different values because KitKat is now trying to use the more modern,

instead of OM adjust, which is in the OM, which is the OM uses, it now uses OM score, which is what is current, the OM adjust is deprecated. With more regularity in the OM score, you'll see a maximum level. So,

so yeah, actually the low memory dealer has changes now that actually if you feed it numbers like this, it will actually look for those and then adjust it to the newer mechanism. Okay, so you can see the min-free. Min-free values, these are basically,

these are, and so if it gets down below 2,000 some pages, it will start looking for the lowest priority apps to start getting rid of those that need to, and then so on and so on. So these correspond to the category and then the point at which they will be

considered to be killed. And this is also in the process list Java file, and you can see here, you're basically defining which categories that these are for. So all this kind of works together, you can see these are exactly

the top line is actually exactly what you need to be adjusting the values. Now, this last two, this min and min-free-low and the free-high, now, in this file, you have an algorithm that basically

tries to find a nice value for your device. Our device is special of course because we have a very high-resolution device, and we have very little RAM. So we did make some modifications to this, and so that we had something that ran better for our

device. And so you want to know how this works, you can basically look at the dump system in Menlo, it will basically tell you how your apps are categorized at a certain time. And you can see it starts with the most important thing that goes down. And so

that will pay the amount of RAM it's using. And then you can also look at dumpsys activity over them. I should actually point out that for dumpsys in Menlo, you can actually give the process name, it actually gives you detailed information about the actual process that's running. And on TikTok, they've added actually a couple more categories which makes it a lot more

informative. It will actually tell you how much the graphics layer is using, how much native memory you're using and things like that. And that will give you a lot of information. Dumpsys activity over them, this basically has three sections of it. You have the

OOM list, this is the current list that we saw, that we said before. And then it will give you a bunch of information about the process of OOM control. You can see you can see the second line of the output or third line I guess, OOM maps and that will tell you about the maximum as it can be. Other than you can look over here, you can see

what the current is. It goes off the screen a little bit. And so you can get a lot of information on using this. And I'm actually going to be writing a blog post about details, what each of these actually brought here to me. So if you go over the blog in a couple of weeks, you'll see there.

And then you can see basically the garbage collector. You can kind of see what's viewed for the garbage collector. So it's interesting to look at what you're trying to debug for your system. Okay, so I'm going to hand it over to Yannick now.

Okay, so lastly we want to talk about the kernel. As we just said before, Android has some modifications to the upstream kernel, but it also benefits from the features that are there.

Yeah, features that were added by Android are like wakelocks, ashmen, and things like that. So the first thing is PSM. It's kernel same page merging. So this was a feature that was thought

for virtualized environments in the sense that when you have several algorithms in your machine, you're probably going to have a lot of pages in memory repeated. So what this does is merge the pages that are repeated.

you only have one page really in memory. And this page is going to be read-only, and it's going to follow a strategy of copy and writing. So when you're writing to this page, you will get copied. So you will lose this benefit. Before we talked about

site and how it allows to share pages to the spawn apps. So this is more like the same, but the processes don't have to be related in a parent-child relationship. So it does with unrelated processes.

So this was added in the official KitKat for the maintenance of the device use. And you have to be a bit careful with this, because when comparing pages, it consumes CPU, so

yeah, probably you need to find the right methods for this before you know it. So how to do KSM? It's very easy. Just go to your CSS and put a 1 there in the run, and put some values in sleep.js, which tells the

KSM how much time should you sleep between scans. And you can also define the pages to scan, so you can scan 128, for example. And you have to find the right methods for this. You have to test how it affects

your battery, and how it improves your performance. And you also have to mark the pages as mergeable, and you can do this with the mAddBites function and passing this maybe mergeable. So

LSP KitKat only does this in the mAdd function, as you can see here, and only does it with private and anonymous pages, so that's interesting, because in Xamarin mods they've been using this for a longer time, and they do it when the sideguard

forks the processes. And they do it with the heap and stuff values, so that's interesting. And how do you find if it's working? Well, just ask our friend Dantjes, as usual. So with Dantjes we mean you can see the amount of memory

saved, and the amount of memory shared, and we reach values of 20 megs, 20-25 megs in our device, if it runs in enough time. So the other feature oh, I should mention that the KSM is in the upstream kernel, whereas

this extra-facial bytes is not in the upstream kernel. So I'm going to try to explain this graph. This is the how the system looks when you're running out of log memory. You have these watermarks, high pages, low pages, mid pages. So when the memory

goes below the low pages, the kernel is trying to it's going to try to free pages with a daemon called please.d. So you're getting a dangerous result, because if you get below the main pages you cannot allocate more memory. Only the

kernel can do this for its own purposes. So you have to stop the app and that's the question the free page, and then free a page, you know, wherever you want I mean, wherever you can. So this often causes IO, it's very slow, you want to avoid that.

And they added this extra-frical bytes feature for exactly this purpose. And so this extra-frical bytes feature you put there a value and it makes the delta between mid pages and low pages bigger. So you can allocate

memory without running into this IO. And Ksoppy also has more time to free pages. So in KitKat it's three times a string with full resolution and full color. So they do that

in order to avoid entering this model called Direct-to-String. Well I hope you understand that because I'm going to mess up if you have questions about it please ask. And yeah, that will be Chris. Please run.

I should point out that this is pretty much the end of our talk but I should point out that we're actually not running on the other day, we're running on the same time, and we're actually on, yeah, 2, 10, 3 1, 2, 3

and so we often find the stuff in KitKat is actually, the importance for us for KitKat is that Google did a lot of work to improve this. One of the most important things they did is actually added a bunch of documentation. I wish they had done that earlier because most of the stuff we found out the hard way. But now actually it's pretty, it's

well documented. There's a page on the AOSP page AOSP site there's some guidelines also so it's actually improved the situation a lot. So like I said before, I'm very interested if anybody has any other input, ask questions

or make comments or think about that afterwards. So that was it though. Alright, thanks.

A couple of questions. Yeah, and that's actually in their guidelines and that's actually, yeah that's in their guidelines we found for our system it didn't really, yeah we have

unique characteristics of our system and that was not something that was for us useful. So, but yes, zram is documented by Google as being useful. Any other questions? Comments?

Yes. that's for future where there's a patch in the kernel meaning. Ok. So that's just for future where there's a patch in the kernel meaning list it's about the wall-tab pages and what it does

is it's allowed to mark the pages in the wall-tab or on the wall-tab so when the graphical system is on a fresh memory it's allowed to actually dump the pages. So you can mark the pages in the wall-tab to get some pressures how to spot them, so you just don't dump them. Yeah, I know that.

If you try to access the page from your application it's going to give you the send signal, so you get the address and then you enter your code. So you get all steps from the browser I can only keep a page from a single tab and I can dump everything else. So if you over-open the tab you tend to re-compute

and re-draw and render everything again. But that's not even thanks to me for having that. Yeah, there's more patches we've been looking at there's one, two, and... Actually, I should say it's not really a patch, it's already in the 3.2 kernel but we have still a 3.0 kernel, but I just back-ported something in the 3.2 kernel

which is interesting for us instead of having it. But that basically improves the you don't basically request direct replay in the allocation path but I don't think that's related to what you were saying. Yeah, I'd like to look at that. And there's a thing in front of the page

well, I can tell in the case of j-matter using the wall-tab pages and whatnot. Yeah, absolutely. We can point to it.

This is what I'm going to do now I'm going to find more applications on Windows one. These kind of things I'm wondering if I have not reached this point I've been

so far, but I'm going to get there so I'm just going to really introduce some other things maybe using the binary application you'd use it to communicate with the other parameters you'd use more or less I don't know.

Probably something we should probably talk about afterwards, because I'm not understanding what we're talking about. Yeah, I know there's some I don't know the other few. I didn't actually

Anybody? You'd write an application on that or that file and the way they communicate with the entire Android runtime you should take a look I'm wondering if you have seen anything that happens, because normally

the main code is less known and so I hope Not really, because the bytecode is more run-back actually, the native code it has to be funded to get user registers and everything Oh, yes Yeah, so

the native code is bigger than the Java bytecode I was just thinking the same as you, and I researched a bit and it turns out so I think it's not going to help much in performance

maybe for us

I'm going to

see more of the other people in the room and I hope to see more of them and I hope to see

more of the other people in the room So yeah The final part of the demo is to

We'll see you in the next video.

We'll see you in the next video.

Thank you.

Thank you.

Thank you.

We'll see you in the next video.

We'll see you in the next video.

Thank you.

We'll see you in the next video.

We'll see you in the next video.

We'll see you in the next video.

We'll see you in the next video.

We'll see you in the next video.

We'll see you in the next video.

We'll see you in the next video.

We'll see you in the next video.

We'll see you in the next video. We'll see you in the next video.

We'll see you in the next video. We'll see you in the next video.

We'll see you in the next video.

We'll see you in the next video.

We'll see you in the next video.

We'll see you in the next video.

We'll see you in the next video.

We'll see you in the next video. We'll see you in the next video.

alone to have these things. So here is a typical startup for networks. So it looks like you get a finder here and some messages about hardware stuff, and then this typically comes on here. You can have it scripted in networks. It can be thrown away. You can do it differently in all these things. And then you get a combined line, and you can do

things here. We have all type systems. Basically, the rapid file system, which is mounted to slash, shift, real month, something like that. We have a wide file system mounted to that, and the environment is copied to that path here. And then we have a command line that very much

feels like Linux. Linux usually, if you're doing bootloader stuff, then this will feel really timely. From time to time, you do things like typing boom or something like that. So sometimes one thing you forget is the real deal. And you can do things like that.

You can see things in here. We have a wide number of that here. You can see this. And one really important thing, if you bring up hardware, is that you are able to access them. Look around, look at directions to us, try to find out what's going on with things like this.

And what we are doing here is, for example, we have a command line here. And that usually works on that end. You can just look into the bootloader that we're going to be processing here. And if you don't want to access the normal physical memory, you can also use one of the other drivers

for example, like in this case here, one of the internet files. And if you add the word switch here for 16-bit access, you can see that you can just access the 16-bit word registers of this file. So that was pretty much it.

Keep up the stuff. Just find out what's going on with the hardware and to bring up new electronics. One of the most interesting concepts is that you can have a tile system. You can just start copying things all around. You don't need any special commands for that

anymore. Remember catching the kernel from somewhere and putting it somewhere, somewhere else and some other address. When I worked on a new boot, I just confused all these hex addresses. That way you had to copy the kernel to all these things. And all this becomes much easier. Like if you look at, for example,

this here, you can see it's just copying from F90 to well, to somewhere in the file system and you can just say I want to use this device and you don't have to remember about this device and what the correct answer was. So it's quite useful.

It's also possible to ask partitions like, well, when your kernel starts it usually needs some idea about how your flash is partitioned, not-flash, not-flash, all these things and we have an end part as well and you can just do the string here

which specifies the layout and partitions and that one is able to access that and it's exactly the same so if the kernel needs to you can just take that over to the kernel and continue there. Another interesting concept is device memory rules.

For example, a device like the first F90 device here can just have parameters. So if you use def and for command here you can call def and for vch0 and then you see what the driver outputs for this device and here you can see what kind of parameters it has like the address and so on and you can just send it like

like this. So sending memory rules for a device is quite useful. Also, if you need to turn on the IFT for example recently there was a war going towards having things automatically mounted

so you can copy things from the TFTP file system and things like that. So that's all quite easy and it's very abstract people tend to do it all the time. Okay. So this was basically a short introduction for those of you who are not coming with DevOps yet

and didn't work with the in the past just to get a little bit of an action to how it looks like and the next thing I want to talk about is the 3D desktop boot level specification and if we remember this image here when we actually started the system here came to this

two point and I wanted to call into one of these, well, call it distributions or Linux systems and we have, in fact we have one problem when you have actually started the kernel then it's quite clear how the next steps look like

you can give the root file system variable to the Linux kind of pipeline and all these things are quite clear but at this point here where you need to do things where you need to find out where your root file systems could be

there is something like a gap in the specifications because when all these things came up, half of it was quite fixed there was no no big well, I don't know black classes like USB memory sticks or SD cards or anything like that

when you basically knew that you had some offness or something like that in your system and there was nothing dynamic in that today especially if you don't look at these CPU devices things like Macbooks

or PC-like devices quite often you can just plug in an SD card and start from that and you basically don't know anything about that you want to look inside you want to inspect that and you want to find out what's in there and this is basically something where we have a gap in the specifications

we looked around how the big distribution did that today especially on different ARM targets and for example, if you look at how Ubuntu works on, for example, the x53 big start board or the handa board or the x100 and so on

then we find out how to do this for months take this one and then a lot of instructions you need to do in the right order and in the end you get your system basically the same if you look at Debian on different ARM systems also more or less

you look into some VTE you collect your commands to do the right things and then in the end it starts up and when the credit is not running then all the systems feel almost the same fedora on the same thing here it's for every distribution

if you look out on which ARM was there, it's important you will find that it's a completely different set one distribution has been tested by some people on that hardware and the other hardware and they were going to opt and then it is supported but there's no generic way

here's where we have this gap between the bootloader and the kernel and there's nothing which this is a unique file that we have so far so it's basically the end of the process since I told you a lot of reading and the miniature distribution could not have

general ARM support for any board which is available but you can just more select on the page boards so some years ago there was this nice commercial here in German computer magazine some company I can't think of this here but some companies

it's all different it can take well strange paths here so this is basically the situation we have today we have a lot of interesting hardware here we have a lot of distributions here and for any of these you need to define something special

this is where free desktop or Google specification comes in and this tries to build this gap and tries to invent something here which will change support for these devices and makes it possible to discover what's in here I'll show you some examples in a bit

this is where you can try the Google specification coming from the startup people you know that they didn't know who this would be or how was the code I don't know okay these people have invented that

and what it basically does is it offers a standard method how to find a partition to use as a boot and it defines these bootloader entries which contain a broken text file where you can just try one of your

operating system images you might have in your SD card for example just take a laptop with an SD card and put the operating systems on the card and these entries you find what's in there you have a directory here you have a machine ID you have a current ID and a device tree

so if you look at this and talk about this this is what we currently care about one of these embedded words or another one socket FPGA you see this completely different set of here and

SD card or something like that what the bootloader does it wants to look inside it wants to find out what's in there and it wants to select one of those or it can use any algorithm to choose between these types so how does it find

a boot partition and the arguments look for special partition with type OACA and on GPT it looks like before this do your ID here and it finds that it uses that as boot

and looks for these entries and the entries look like this one here you basically just have a test file with the title and version the machine ID options, Linux, init RV and we added the device tree to the specification we first write that on an embedded arm this option wasn't available

it was added to the stack recently and this is basically everything the bootloader needs to know about that boot target and if you have this information well that's basically all you need for one of that and that's what I showed you on my first image

ok, so what can you do with a bootloader specification when you have the system up and running this is an example here from the famous pizza letter which is one of the first arm basics networks within I think MX51

or something like that for the CPU and if you have that other one you can use that install command here which is coming from the system B project you can for example just tell it that you want to install it

and if you just do that from your update manager it takes care of these bootloader entries these text files and it provides everything the bootloader needs when you start it for the first time to have another entry

for example so this is also communication between the new sudo space and the new stage where you can have it already or you can only use that if you don't want to update alright, so basically we have seen the configuration file like if you remember

format times we have system B support for bootloader tag so you can just install a bunch of distributions in parallel you can have Fedora, Debian and Ubuntu and whatever from one medium and you can even have one of the

parameters of that distribution and all that is just described bootloader and programming file bootloader and then others cover that and what we did with that was we had one SD card and we talked it into several well, completely different

ARM CPU based on many devices and it can just boot remember what the external community is doing right now they are working on getting one unified trainer for ARM where all the decisions, if you are on one model and another one is basically done on runtime

and not on compile time anymore like format times and the combination of these two things make it really possible that you can have one SD card and plug it into different devices and just by updating everything alright so we have a good understanding

of these boot targets now when we start with the strength we already worked on the SD card all types which are running on the x4 file system or in the event that you want to be quite off you have the VMCs

which is basically an SD card VGA case which you can't already install that into your device that worked right on the box and what has been added was open for the support that we can also describe our hardware and support for

hash-based devices real hash-based devices power flash and hash-based devices and UBIFS that was also what you have seen in my first demo where there is limited device so it is just hash and hash included from UBIFS partition alright the second thing which came in last year

we will now have the support for the open firmware device tree the open firmware device tree is, at least in my opinion differently if you asked me some years ago but in the meantime I think it is a very nice tool or method

to just describe hardware to be there and what you have in your system everything which is not always coverable like having certain chips on certain addresses and things and all that is done by Mazzi and the more

this is used the more we thought about that we really need the same information in the bootloader space as well there are a lot of points where you need to access some hardware where you need to do some decisions

based on where the different devices in your hardware are in order to initialise them and what we did there basically was that we added the firmware device tree support also to barebox so you can use the same device tree you are using

for your mainline kernel and put it in barebox and then compile barebox for that and then it does all the initial hardware bring up from the device tree and it looks where all the devices are which ICPSE devices are and what you think and it starts the utilization from there

so from our point of view remember we are thinking of leading to transfer into new hardware this makes a lot easier to bring up news on new ports for example we have a lot of hardware boards we are working on

the Freescale Idol big family for example and if I remember how that works let's say 2 or 3 years ago it was always a lot of low level hacking, a lot of programming writing board files these things, pushing things through the compiler and if you compare that to how that works these days it's basically writing a node for every tree

so if you have written a node you have described your hardware specified where all the devices are when you are basically done you just give the device tree to the boot order to barebox and it works the boot, the build, the driver the device works

okay, the same device tree can be used to start the kernel so you can just hand that over from the boot order to the kernel works more or less automatically there are a lot of nice features in barebox for example that you can runtime patch the device tree we sometimes have the case that there are variants that work let's say it was 512 megabytes of RAM

or 1 gigabyte of RAM if you can't automatically take that you can just write a little runtime patch for the device tree and put that into barebox and so you can just put it there and when it loads the device tree change it to that entry to what you already know

and then handle it off to the kernel and start it works quite nicely an interesting application for that is the declaration of Displace with a binary system which is often used for the Displace for train stops and that kind of applications

and what happens there is that if the Displace breaks it needs to be exchanged the technician goes up there and smiles on the new Displace he doesn't know much about software he just knows how to screw the Displace to the case and all that and what they are doing there

is that they just put that device tree into the new Displace description onto the USB stick the technician just puts it in barebox just reads that description from the USB sticks and runs unpacked back onto your head tree and starts over and so the technician doesn't need to know anything but how to plug in the USB stick and get that description

very nice and makes it quite easy to describe that there is a downside in that and everybody who has done device tree in the past probably knows that device tree very much depends on the ability of the bindings so since we have device tree based kernels

one of the reasons the most prominent reason why the board refers to boot is that something changed in the device tree and someone at home wouldn't take care of that the awareness for that grew quite a lot

in the kernel community recently and the kernel developers are really really taking care of not changing those device tree bindings it doesn't work in any case there is still a reason for for booting these days but it has become much much better if you try to show it

alright, some other abilities for example we have multi image support in barebox here with multi image support it's easily possible it's quite easy to build multiple images from the same config we have the case that

we have one barebox configuration remember that's just kconfig we try to make menu config and then you can change things and sometimes you have a whole penalty for different devices with different CPU's or something like that on a big stage for example

which are just a little bit different but it's possible that with the kernel you can switch on all the different variants in kconfig and the build system automatically builds a lot of images it makes it quite easier to have just one compiler

to generate a lot of other things a lot more better compiler coverage and for these auto detectable devices there is a nice attack command now so that on introspectable like USB or SD we don't

know before what was in there and usually you have the situation that if you look on any boot what's on that USB bus for example, this needs quite a lot of time if you want to achieve fast boot times like in my video with 5 seconds up to the point where the application is running

then you usually can't go to all the possible buses, SD cards and USB until then and for example in that case I told you with the train this place what it does there is it looks different USB speakers connected and only if it's connected it runs the tag and looks what's in there

and tries to do something and all the protocol level and utilization so that's also quite nice and we can for the first time try to take a look on the device and once it's on device A and this is quite new

this is an excerpt from the Pentronix internal IRC from Friday evening Friday night now Friday evening here and where Pentronix here is working and this television VPT device is a Linux 27 CPU

which has a television receiver on one side and a network on the other side and you can stream television through the network and this device is working on NFS version 3 support and as you can see here you can have a look at

the file system on the server here NFS version 3 is pretty important for us because if we have that we can basically get rid of the requirement to have a TFPP server for development if you're doing good early development in most cases you will probably have a TFPP server running because you need to fetch

your kernel from somewhere and we can do the same thing with NFS and the interesting thing there is that you can use user space in NFS and you don't need to install anything on the development machine anymore installing things on the development machine is usually something where you need to do a lot of things correctly

choose the right TFPP that's one of the easy tasks sometimes there are still many different ones with different drugs and different features and we try to get rid of that and while we are also working with PDAs but across the whole system and PDAs we have a feature we can just run a command

and then expose our root file system and now we can also expose the kernel via NFS version 3 all from user space without needing root access and then look at and do more things so it's quite new to give today's knowledge and not even the new report for example

and I think quite an interesting thing which makes development a lot easier alright, so if you want to try that this is the most important communication channel there is a website www.ric.com and we have the main news tier

which is the main communication channel where you can send your patches and all that alright that's my talk thanks for coming do you have questions?

I've seen the new there was a filter update support in bedbox would you elaborate on that?

filter update in which sense? I mean I've just seen a menu option I don't think a menu of bedbox had an option I don't know exactly what you mean maybe just something we can look later on and have a look at the sources

maybe for PDAs in the idea of your market share your competition is essentially you boot and do you have any idea on how many of you are choosing one of your projects

well basically the thing is that we don't really see that as competition it's all open source somewhere and for us one of the most important well things behind doing this is getting more problems so we usually look at what other

projects are doing we are looking at what you are just doing we are looking at what the kernel is doing from time to time it's a nice thing to do you just take something from there to your environment and the other way around I don't see this as comprehensive deviation or something like that it's just all this

vibrant source community and everything is crashed well a lot of this would have been possible without you being there good question

what about you, EFI support any plans and status yeah I think that Sascha Halber who is the maintainer has already looked at what's possible there and there are also ideas like

I don't say anything there are also some ideas in all the interfaces in barebox but it's not there it should be possible and somehow the other way well we continuously look around what's going on there basically

the idea behind all that is being able to look at the universe is changing over time and also the methods how the kernel direction is changing and we definitely know what will happen during the next years there's all this heated discussion

about basic API on one side and doing QFL and then it takes on the other side and doing QFL this kind of thing I think it's quite interesting to observe all that and in the end what we need to do is to make the script for the hardware

and whatever is necessary needs to be done so you mentioned at the beginning that you introduced some programming ideas specifically I don't know

if I remember right but there's a kind of driver model for barebox so I'm assuming there's this Linux kernel driver I would like to have for that reason how hard would it be to port a Linux kernel driver to the bootloader

how hard would it be to port a Linux kernel driver in general that's pretty easy in fact the driver model in barebox looks quite similar to what the kernel has I mean it was entirely inspired from there and what you basically need to do

is you need to get rid of all the parallel executions we haven't had the drugs in barebox I mean it's still the bootloader although we have all those nice heavy things and in some way it's like if you look at Linux well back in the 2.4 days or something like that where you didn't have SMP

and these kind of things so that's basically taking a driver from the kernel if you're going to need to well, making it easier and more parallelism and that works quite nicely in fact we don't really like this because it's code application and we don't like code application

like anyone else is working with that but if you look at my use cases with all these fallback images and things like that it basically doesn't work without any instance which takes care of a decision point or the algorithm is about to choose

which partition it's basically what still drives that you think you need a bootloader even today things like just writing a kernel is no real option there are use cases where this is an option there are a lot of really good use cases

out there it really doesn't work thanks other questions? ok, thanks for being here and if you have any questions you might also come