 OK, I think we're ready. Maybe not. I go. OK, welcome, everybody. Welcome to MIPS both. Thanks for coming. So I will give a presentation of what happened recently and the MIPS world, and especially in Debian. We all have seen MIPS in the last year, like slow architectures with plenty of things on the working. People not really caring about it. But things are changing. So in the last year, in 2012, Imagination Technology has bought MIPS. And first, everybody has said, OK, it's the end of MIPS. They have just bought the company to get all the patents, and they are going to stop the CPU. And that was wrong in practice. We have seen plenty of people on the mailing list, on free software mailing list, on the kernel, in the tool chain, QMU, and plenty of other software, starting to send patches with the email address of EMGtech.com. So they really contributed a lot of patches, things are changing. And there is a small plot about the upstream links kernel patches that I went to the mainline. And you can really see the difference between the time before Imagination Technology bought MIPS and after. And especially in the 315 kernel, there have been a lot of patches, including virtualization for MIPS. So things are really changing. And we'll see on the hardware, it also changed a lot right now. If we look back in Debian, where we have in Debian for the MIPS ports, we have two ports, a big Indian and a little Indian ports. There are both 32-bit ports. So for people who know, but that is the O32 ABI. It's really all ABI so far. And in Debian, we have kernel targeting various machines. Most of them are 64-bit machines, except for the multi-development board, we also provide a 32-bit kernel. So the long-sum 3A and 3B machines are relatively recent. Multi-development board are also still developed and very recent, but the other starts to be a bit old. And if you have package in the archive, you may all know that the MIPS will demand us slow. They don't have a lot of memory, so your package often fail to build there. But we are working on that. So for MIPS CL, we already have some replacement hardware received from my imagination technology. So we have three new long-sum 3A boards. So they are called Eberlin, MIPS CELMANDA1, MIPS CELMANDA2. They have four to eight gigabytes of RAM, so we can build any TMPFS using a lot of swap. For most packages, it got a lot faster. They have four cores, so we can build packages in a decent amount of time now compared to the previous machine. We will get soon also long-sum 3B machines that we arrive in a data center that is in leads. So thanks to imagination technology, we got of contact with this AQL company and they will provide for Debian a full 48-year rack for putting a MIPS machine, but also other machines. And that's what you have on the photo on the bottom. There are the three opt-on two machines that are waiting for the MIPS port. So MIPS CL now is going pretty fine with regard to the build elements, but MIPS is always slow, at least 20, 30 packages in the queue. But we hope that to change in the next weeks when the rack is all wired, we are waiting mostly for a switch now to run it. And if we look at the problem of these ports, we see that a lot of packages starts to fail with the failure of virtual memory exhausted. So people often ask us, oh, can this package can be retried on a build them on with more memory? The problem there is not the memory of the machine, it's just you have in a 32-bit world, you are limited to depending on the architecture to two, three, or four gigabytes of memory per process. In the MIPS world, the way the address space is done, you are limited to two gigabytes, except for recent version of MIPS with the EVA extension that are limited to three gigabytes of RAM per process. So we are seeing that to happen more and more often and there are even I386 package that failed to build on I386 due to that. So clearly in the long-term, all Debian ports are going to switch to 64 bits. And also it's worth to be noted that the MIPS and MIPS CL ports target real old ABI, which is a MIPS 2 ABI from the F4K era, so for the old SGI machines. That's why we are looking for getting new ports that are faster and reusing better the hardware. So first there was the MIPS N32 ports, so both in little and big version, that has been a subject of various Google summer of code. And the idea of this ABI is to use a 64-bit registers because most of the CPU on the MIPS world have 64-bit registers, and but keep 32-bit pointers. It's like the X32 ABI on the I386 world. The main issue, it was probably a good idea five years ago, but now we are at this architecture is still limited to two or three gigabytes of memory per process. So it might still work for now, but in a few years it will be a problem in Debian. Mostly it happens with GCC or BNutils, when you try to build a big C++ code and try to link it, you need a lot of memory. So the other problem is the fact that you have 32-bit pointers and 64-bit registers, and there are plenty of code mixing pointers with long and integral values, and so there is a lot of code to pass. Of course the code is broken that way, but it exists, it's like that, and we probably don't want to spend too much time on fixing this, especially that people continue to write such code, so it's a continuous process to fix it. So we are not really interesting by having such a part in Debian anymore. What we are interesting to have is a mid-sport targeting the N64 ABI, so it's a 64-bit ABI. Well, we have told us most TPU are 64-bits already, so it's not a problem, and at the same time we want to increase the minimum instruction sets that is necessary to run these ports. We want to target the mid-64 ABI so you get more instructions, and probably even the mid-64 ABI, it's not fully decided yet, so you can have more instructions and really better use the hardware. Now if we look also what happens, the most hardware that is being sold today are either little and young or big and young. So for now, we only think about doing a 64-bit little and young port, and their experience has shown also that supporting a 64-bit big and young port like the S390 export or even Spark 64 is difficult. There are plenty of ugly casts between pointers for long and twint values in the code, and so it has to be fixed, but with MIPS and it's like with Spark, you also need to enforce the strong alignment, otherwise you get sick bus, and that means ever less code is going to run. That's why so far we are only interested to have a 64-bit little and young port. And so there is already an official mid-60 ABI port. It's currently hosted at this URL, and right now it has a 909,000 package built of 10,900, so almost everything is built. During one that are not built, are just most of them out of date because the build elements were only too much and they are not fast enough. There are only two long-sum tray-based build elements. And for the other packages that fail to build, most of them have the patch in the BTS, so it's just a matter of getting them merged, and then we can get the mid-60 or 4-year port. And we expect to be able to enter, to put this port in the official port in the IBM archive soon. We are mostly waiting for additional build elements to the MIPSi L1 to be able to build the packages fast enough. I want to talk also about what's going to happen in the future. Imagination technology is currently developing MIPS L6 ESA, so it will bring plenty of things because even the mid-64 ESA is based on very old ESA from the L4K era, I mean, there are new instructions, but you cannot get rid of existing instructions, otherwise you break the compatibility. And actually that's what is going to be done with the L6 ESA, so the idea is to support and align access to get rid of these delay slots that people probably know about that, that's after a jump instruction, the next instruction after it is also executed always. So that was done at the time when the instruction execution was fully sequential. Now most of CPU are using auto for their execution, so it doesn't really make sense to keep that in the CPU. And it's actually the same for the multiplication and division instructions. There are two registers, I and low register, that store the results of this instruction. The idea was that given they take a lot of time to execute, you start your multiplication, your division, there is a separate unit in the CPU doing the computations and providing this in separate registers. That means the other instruction can execute in the meantime. That was already a kind of auto for their execution, but now that the whole CPU is auto for that doesn't make sense to keep that. So this instruction are going to be removed and new instruction is provided to do that directly in the normal registers. You, this is also add some program counter relative load store instruction, which is very important for a position independent code, which is something that's more and more important, especially with regard to security and with libraries. It adds the select instruction, so it's the instruction when you, depending on the condition, you load one register or the other one. And it provides also a FPU compatible with the i337542008 revision, which provides plenty of additional instruction, like the minimum and the maximum of values. So this is included in this user. So it's something still in development. We expect that to arrive, the hardware to arrive in about six years, but Imagination Technologies already provided patches to add the support to QMU. And I told that the new ISA will break the current ABI, but there is possibility to build binaries using the common instruction set between the previous MIPS CPU and the new ones. So at some point we might want in Debian to rebuild our binaries to support both and do kind of a transition, and that if you might want to do new ports depending on how the hardware is going, a bit like it had been done on the ARM board between Army Air and Army HF when Army HF targets more recent CPU than Army Air. Then I'm going to talk to you a bit about a board that can be used for development. It's a board like a bit like the Raspberry Pi. That's Imagination Technologies developed. So board that is available there. You can see it after the talk. It has a dual core 1.2 gigahertz CPU. So unfortunately it's only MIPS 32, but for running the MIPS CL port it's not a problem. It's little and then only. And it's as an HDMI output so you can use it on a fuller screen. Unfortunately it's not compliant with the setup of the video team there so we won't be able to show you the output of this board. It has one gigabyte of RAM, eight gigabyte of flash. You have an internet connection. There is even wireless and Bluetooth so you can work, for example, in the R-Club on it without needing an internet connection you have the Wi-Fi for that and it has USB port. And more importantly, it runs by default. It's shipped on the flash with Debian Wheezy. So there are very little changes, mostly the kernel and the two firmware and by default it's changed to running XFC but very few modifications. So that's something great and it will be probably possible to get also Debian JSC running on it. Probably with just the kernel because the patches for the kernel are being sent right now and it's probably going to be too late to be included in the Debian kernel, that's there. So you are a bit too far. There are some photos of the board. It's all arrived and the two sides. The first batch of board is only for developers. So I got this board from Imagination Technology. So I have to say I received it just before the outcome so I haven't fully played with it yet but it was quite interesting and you can follow the link there and Imagination Technology offers boards for developers who have a project describing how to use that. It will be later available on the market but right now the date is not yet known. And if you want to see it running Debian with you, let's, that's when it runs. So it's a very small board compared to the screen and the keyboard. And if you want to, I don't know if it's fully readable but a comparison between the C820 board, the MIPS board and other ARM-based boards or the Raspberry Pi, B plus or the Big Apple Black. Basically the CPU is faster especially that it has dual core CPU. You also have a faster GPU on it that's supposed to decode or uncode H.264 videos. I haven't tried. I don't know what is the status yet with regard to firmware if it is free or non-free. I think it seems at least in Debian what is installed to work without any firmware and without any binary driver. I have to look more at it. So it has more memory also and what you have also is the wireless which is an addition to Raspberry Pi. You don't have to plug an external Wi-Fi dongle on it. And you can plug a camera on it. Also, there is an interface for a camera. There is plenty of IO if you want to interface to the outside world. And there is even an infrared receiver if in case you want to use a remote controller. I haven't fully played with it. I can boot the board maybe if you want to see there is not a lot because we don't have the screen so it will be only through the airport. Those of us who are open to question we are open to question discussions or don't hesitate to ask things there. In the meantime, I will boot the board. I have a signal cable. So if you switch to ISR 6, then is the idea to allow backwards compatibility by having processors running R5 instructions on the same kernel by possibly trapping the defined instructions and emulating the main software? So because on ARM HF you can still, even on ARM HF cable, you can still run Army or Binary. So I think if we switch to an R6 port, then we should at least make sure that you can still run the old Binary for a while. So far I don't know if anything is planned. It's really the beginning of the R6 API. I mean, it's public so far as the instruction set is public. You have it on the MIPS imagination technology website. The problem here is that they have removed instruction but they reuse the encoding space for new instructions. So I don't know if it will be possible to trap or not the instruction. It depends on the implementation. They could just have a bit where you say if you switch, where if you enable that bit and the new instructions will not actually, will actually cause a fault instead of. Maybe that's something possible. I think it's too early to know about that. Imagination technology is working on keep that compatibility and that will be some feature that will be transparent to users. Any more questions? Just unplug it and unplug it again. So you talked a bit about. So yeah, it's, oh, sorry. I was saying the board is booting right now. It's using Uboot. So the sources of Uboot are available and the sources of the kernel are also available. It runs an UBFS file system. Something new to me, but right now it's loading. Now we can see it's loading the, maybe increase the size of the font, loading all the device and it takes a lot of time to recover the UBFS file system because I just unplugged the board and plug it again to reboot it. Maybe can you ask your question? So that looks promising in the new ports, but you didn't talk anything about the old ports. So. About the old ports? Yes, it's in the Intel. Yeah. So during the last two years, there were a lot of promises to work on these. There were a lot of promises to get help for these ports. We have got a lot for it, yeah? Well, apparently the MIPS portal machine doesn't exist. The MIPS cell machine is unstable. The built-ins are slow. No, the build-ins on MIPS cell have been replaced. So we have launched three machines. So they are not. The portal box, the portal box, it's me, I mean. The portal box is still the slow one, yes, but we are waiting for the new machine to switch the portal box to the new machine. But that was promised two years ago. So will this happen? Or I just fear that we add two new architectures and don't get rid of the old architectures. And I can't see that anybody is working on these. Well, the hardware is already there. Just for example, in AQL, the hardware is there. We are waiting for the rack to be set up. It's not so easy as expecting to get everything working. We received the hardware already six months ago. So just take time. I think in the next weeks, really, it will be wired. So I'm really asking, is it possible or is Debian able to support four MIPS architectures? No, the idea is not to go to four MIPS architecture. The idea is to go to three right now. We don't want 64-bit big Indian ports. We only want a little Indian. And yes, the idea in the long term is to drop MIPS and MIPS here. And maybe it will be for Jesse who want to keep them. For Jesse plus one, maybe we'll have to drop them. Why keep them? Because otherwise, we don't provide any port with Jesse. And they are still working fine. Look, there is a Jesse that can work on this board. Well, working fine is something which isn't that true. So debugging currently on the machines is, well, set up a CH route, try something, find, well, the machine is rebooted for several reasons. Yeah, I agree there is a problem on this board, yeah. But the new boards are there, I have a photo of them, even. Well, I don't care about the photos that you showed me, the photos two years ago. No, no, these photos are new from two years ago. So is here anybody in the room supporting MIPS as a porter in Debian? We have the machines ready to be installed. We have a problem in Debian, Debian is moving very slowly. We are trying to get more machines working, and DSA needs more people to help with this problem. So it's basically, we got the machines ready to be installed maybe two months ago. But DSA is moving very slowly because they don't have the manpower. And also, I mean, we are going to install this machine in the data center. It's a new location for DSA, and it takes time to arrange all the details. And the new data center in Leeds that we have is because the data centers that were in Germany or in other places, they didn't move quick enough to get these machines up and running. For the Lonson 3, we wait three months, the machine were shipped, they arrived, and we wait three months before they've been racked. More questions. So how flexible are the existing MIPS curdles at the moment? I mean, is it feasible to have a single Z image that will support lots of devices, or do we need to pick specific board support? No, that's currently an issue, and we need to have a canal support. So the new canals are supporting more and more boards before it was one canal per board. Now it's more like one canal per type of CPU. We will have to get through a common canal at some point, like has been done on ARM, but so far it's not yet ready. There is already device 3 support in MIPS that works, but device 3 is not enough to get it working. You also have to get all the devices converted to device 3 and get a single canal after. And on MIPS, you have all these soft TLD lockups, and every CPU does it differently, so that's not so easy either, I guess. And ARM architecture is, even the ARM architecture is more standardized because like on MIPS, you have soft TLD lockups that you have to really synthesize your soft TLD lockup code per processor, which I think makes it more complicated to make a single canal for it. I think right now MIPS is in the same state than from the canal point of view than the pre-V7 ARM, where nothing was standardized and we had to get plenty of flavor. Since ARM-V7 standardized a bit the things, yes, a single canal was possible, and maybe the new ABI will also specify more of the details about our booting a CPU. And maybe we can expect to have a single canal. Right now it's really a problem also that when we get new machines, we need to have support and stable for this canal, or in back ports, but it takes time and often we are waiting for having the canal before being able to use the machine. So, I remember that I was at some point yet another, so there are many MIPS ABI, but there is N64 and... N64? And there is, and there was some proposal where MIPS Technologies was not yet part of the imagination to have yet another new ABI which would be, exist in both 32 and 64 with flavors and would be somewhat similar to N32 and 64. But, yeah, different. I don't exactly know why it was different, but the web pages are still existing. So, has anyone considered reviving that proposal, or has anyone investigated why that proposal was made and was supposed to be better than N64? Because now, if you decide to now switch to a new ABI, maybe it's worthwhile, and we don't have any legacy backward compatibility on N64 anyway, it might be worthwhile looking into if that proposal makes sense or not. I guess the only reason you would not want to, as if you want to have compatibility with Ilex N64 binaries, which probably no one in the world counts about anybody. Yeah, but the MIPS word N64 is quite standard for 64 bits. I know that there was a distribution using this ABI, and I know that Kavjom has an internal distribution using N64 source, and it also means that all the software that I've assembled code is using this ABI. So, probably we don't really want to switch to an ABI that is not fully supported in the world. So, yeah, with plenty of porting to do. But, yeah, at some point, my investigators also, before doing that, this new ABI is more promising or not. But it looks like that, I have to say. Yeah, I'm not sure how far they ever got to it with that idea. I remember at some point that it was sort of like set in stone that they would move to it, but then it all disappears again. I'm not sure if that actually has been, there have been patches for tools, to toolchain, to manage that. I don't think so. Oh, this is only the wiki pages. The ABI that you were mentioning is N32 big. The reason that N32 only has two gigs of virtual address spaces because the pointer winds up being sign extended. Yeah, exactly. And you lose the high bit. The N32 big ABI was going to just change what happened to that bit. So, you actually get four gigs. The person that was going to do that then decided it was a bad idea because I think we have enough ABIs already. And if you want more than two gigs, you should probably just use a 64-bit ABI because you have a 64-bit CPU already if you're running N32, so. That's true, the highest bit is defining if you are in a user space or in kernel supervisor space. In the new MIPS L3 instruction set, you have the EVA extended virtual address modes which allow you to use this IB also for our user address space, but you need for that hardware support, which is not all hardware yet. Probably it's better to use 64-bit directly. Just kind of funny because the A6 world is exactly doing the opposite by claiming that they have a performance advantage by especially on smaller chips with smaller caches to have process which do not actually need four gigabytes of, more than four gigabytes of virtual address space to keep the mass 32-bit, but at least keep the pointers in 32-bit and use the 64-bit which always has been the idea of N32 and N64 in general. The idea was that you only use 64-bit where it makes sense for maybe like this decompiler or anything which requires lots of memory but not for smaller programs. Yeah, I think that was a good idea four years ago, but now more and more processes are more and more softwares using the four-gigabyte memory. And even now we have a smartphone which is taking with cameras with very high number of pixels, which is probably silly, but the result is that you have big files to handle, big files to, and in the next year we will need four gigabytes, more than two gigabytes at least for almost everything. That's a pity, but it's all the world. Sure, you don't need four gigabytes for LS and Bash. That's true, yeah. I mean, you will need it for GCC, but then, okay, that's still not as if you're building. And the idea there is that also the advice evolving, so when you target, it's like in N64, you get bigger pointers, but at the same time you get new instructions. So overall it's still faster. I guess it depends a bit on how much cache you have, and it probably depends on the kind of application you're looking into. Any other question? Yeah, I mean, continuing on the same point, I mean, there is an ILP32 mode, which people are pushing for on 64 as well. Again, it's all about your instruction cache size and data cache size more than anything else. X32, if it makes sense, makes much more sense on X86 because it gets you away from the utterly, absolutely terrible register limitations on I386. Mix and arm, where you already have a reasonable set of registers already in 32-bit mode. There isn't necessarily the same win by actually shifting over to the horrible mixed or limited 64-bit version. ILP32 is, you know, it's gonna end up coming out, it's gonna get be used by some people, but as a general purpose system, it doesn't really make much sense. Yeah, you don't need four gigs for LS, everybody is aware of that, but the extra complexity of having two sets of libraries on the system and whatever is, frankly, it's a mess. We can do it better in Debian with multi-arch than most other people can, but still, why do you actually need all the hassle? Yeah, in 50 and four. No, no question about that. Sorry, the point might have been made already, but we have packages in the archive that need more than two gigabytes of VM to link, so anything that's, and that's only gonna get worse. So I think any new, any new 32-bit architecture is gonna have problems being a complete architecture, and I'm not really convinced it makes sense to add an app-continuating any 32-bit architectures as release architectures. Yeah, maybe it makes sense for the embedded wall when you rebuild all your binaries before shipping your device, but for Debian who is targeting having plenty of packages, desktop packages, and so on, it doesn't make sense to keep sorts of bits, I agree. At least in the long term, we probably want to keep the existing port for one more release, but in the long term, we have to switch to 64-bit. Hello, I was wondering maybe the problem with the 32-bits and 2GB of memory, could that possibly be helped with cross-building stuff? Yes, you can cross-build it. That's the point, but probably something we don't have once in Debian so far. I don't know if it will change. So far, the position has always been to build natively everything. I don't, maybe it can be changed. I think one of the other is that someone on a machine can just fetch a source, patch the package they want and rebuild it. If you start needing a cross-compiling environment, then it makes the setup more complicated. Now, maybe in the long term, we want to change that, I don't know. I think you can't lightly cross-compile. You always have some configuration issues which you have to look at, package for package, and I don't see it as a default. If you know your environment, if you know your packages, you can cross-compile. But I don't see it as a general solution to overcome the 32-bit limitation or 2GB limitation. Another question? If you are interested in this course, you could register your interest at the web page or you could leave it with us. And we could send you a poll in the mail. It's finished, thanks a lot for attending. Before we finish this, we have an amazing knowledge. It's really great to do all this. If you are interested in this, I'll send you a poll to your email. Can I use Jeff? Can I use him? He wants to send you a poll. So, I'm going to ask him what he can send. He's going to send us a poll. Yes, I'm going to ask him what he can send. He's going to send us a poll. He's going to send us a poll. He's going to send us a poll. He's going to send us a poll. Yes, I'll send you a poll at the end of the day. I'll send you a poll at the end of the day. Right, so this is your poll, aren't you going to do your actual poll in the starting? The poll is yours, right? Yeah, that's my point. Since I've been very active for a while, we've done this thing. That's right. The CSA asked us very simple not where to get. They wanted us to do several or two or one unit. And they don't want the remote. They were quite cheeky about that, so it was very difficult to find out where to go. I'm not very happy that, for example, they had the RCC or even the architecture. Two general reports, but it's not that long. It's the results of the RCC. That is the RCC. And the RCC. They had the RCC. Okay. Yeah, they're keeping the same. I've already told them. Yeah, I told them, but they say... They say... Yeah. No, their opinion there is to change the mix. Change the arm sync. Change the arm sync. No, no, no. I'm not very good at this. I'm not very good at this. But they say that before they were there, we'd get on some 3D. So that's like an 8th course, so we'll be doing faster. Yeah. We're not interested there, but we need to plug them. Yeah, we need to plug them. I know it takes a long time so long, but unfortunately sometimes they don't... Sometimes they don't go very, very fast, I have to say. Sometimes... Yeah. So far on this one, I mean... Oh yeah. Oh yeah. But some things... There will be some hardware and you are waiting for it to be read, so then you want to continue... Yeah. That's... I don't think we're going to... Yeah. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. What? It's in the end. I feel like it would be nice if we had a project that would include tools instead of tools that basically solve the same problems. And people are using QuickSport as well. And work only goes into it. I have one. This camera is in demo mode. But it still works. Which is kind of neat. I actually tempted to zoom in on people. I just want to retire half the project. Okay, it's 11.