Hello everybody. Welcome. I'm going to talk to you today. My name is Mark Corbyn and I'm going to talk to you about my work using build route to create embedded Linux systems for 64-bit RIS 5. I'll start off with a little bit about myself. I work for Embercosm. I'm embedded operating systems lead. I've spent all of my career working in embedded systems, particularly very low-level resource constrained systems, real-time work. Majority of that time I've actually worked on intelligent transportation systems, roadside tolling, equipment, vehicle monitoring, number plate recognition cameras, and developing operating systems for bespoke hardware to support those applications. I've been developing on Linux as a development system and rolling embedded Linux distributions since 1996, and I'm currently the RIS 5 maintainer for the build route project. Today's presentation, very high-level presentation, I wanted to present build route as a quick-to-market way of evaluating a RIS 5 system and getting an embedded Linux distribution up and running. I'm going to tell you a little bit about RIS 5 briefly because I don't like to presume that everybody here is an expert. Some people might come along to see what it's all about. A quick comparison with the other popular build system for embedded Linux, Yocto, and then I'll talk you through the process I went through of adding RIS 5 support to build route, and then a work-through example to show you how you can get up and running build your own embedded Linux system for RISC 5. A little bit about build route now from the build route website. It really sums it up. It's a simple and efficient easy-to-use tool to generate embedded Linux systems. It does build everything you need in one complete package, so a cross-toolchain you can use for an embedded build environment, bootloaders, kernel, root file system image. It supports a wide range of architectures, as you can see I've listed, and specific boards within those architectures have default config definitions that you can use. If you are interested more on build route and its details, you can visit the build route website at the bottom, or you can find various material, particularly from the bootlin website on the internet, which goes into greater detail about the inner workings of build route. A quick overview about RISC 5. Just to summarise the main features and point out Embercosm are one of the member organisations of the RISC 5 Foundation. Particularly good information about RISC 5. You can find particularly the event proceedings I found on the RISC 5 Foundation website. Give you a good overview of RISC 5 architecture. Okay, a comparison between build route and Yocto. I've worked with both systems and they really do offer different things. Build route is particularly focused on speed and simplicity, build sort of cut-down systems and be quick and easy to use. And therefore, it's quite easy to understand and work with and expand as you need. Build route builds you a root file system image, so that will be a binary image that you could blend to an SD card or put directly onto your board. Whereas if you see, Yocto is very, very flexible and customisable, which makes it quite difficult to get to grips with for a beginner in terms of the number of configuration files and settings that you can use. I found a quick search on the internet suggests that there are about 2,300 packages available for build route, compared with about 8,000 for Yocto. Yocto actually builds a package feed rather than a file system image. You can go on to create a file system image, but typically it generates RPMs or Debian packages which you can then use to deploy a packet manager on your target system. The other thing to note is that build route is self-contained in terms of the features it supports, so you download build route and you get everything together, whereas Yocto follows a layers model where you can expand what you have on your system by checking out individual layers for different hardware or different applications that you might need. Okay, adding risk 5 support. Goals really for adding risk 5 support were, as I said, at Embercosm we've been doing a lot of work in the risk 5 software ecosystem and it struck me as a good way to get something up and running as an in-house tool really to quickly put together and evaluate embedded Linux on various systems. It also helped that nobody's actually added risk 5 support to the officially to build route yet, so it was an available project to work with. The choice for 64 bit, as we'll see, was really made by what was available that had been ported for risk 5 already. One of the other goals as well was to look at working towards kind of bringing some of the bespoke repositories in risk 5 into more standardized packages. So, for example, rather than having to go and pull risk 5 tools in different repositories and perhaps put together a system by hand with the various components, it's a nice idea to wrap up the whole process into build route so that you only have one place to go. One of the priorities as well, not for laziness, but was just to minimize work in terms of customizing build route or having to add any special features just to cater for risk 5. The idea was to try and use as much upstream software as possible and customize build routes as little as needed to. The choices at the time, this was back in August last year. The most obvious choice to begin with was the target. QEMU was the initial target. I do now have a sci-fi high-fi unleashed board, but at the time it was the best route to get something up and running to allow people to evaluate the test. As you can see, risk 5 support has been in QEMU since version 2.12, so it's upstream and stable. ToolChains. ToolChain was good to go. GCC has had risk 5 support since GCC 7.1, and I did find that it needed binutils greater than 230 to be able to build a bootable kernel. C-Library. Build route is designed to offer you some flexibility for your choice of C-Library so that you can use lighter weight C-Libraries such as UC-Libc or Muscle. But at the time only G-Libc has upstream risk 5 support, and that's for 64-bit only. Looked at the bootloader. Now, I would have preferred to add U-boot support, but at the time without a hardware target it didn't make sense to do that, so the choice was made at the time to go with the Berkeley bootloader, which is the risk 5 bootloader, and it was not too much work there to add that as a bootloader package to build route. Finally, kernel. There was risk 5 support in mainline kernel back in August at 4.15, but it wasn't able to boot under QEMU. So, I've been using the risk 5 Linux Git repository and using the 4.15 branch for that. That has actually just been recently bumped using the same repository, but it's now on kernel 4.19. Okay, an overview. What do you need to do to put yourself together on an embedded Linux system with build route? It's pretty straightforward. Steps here, overview. Get yourself a copy of the source, either check out to clone the Git repository or download one of the stable release tables. Configuring build route is very straightforward. It uses K-config system. So, if you've configured a Linux kernel before, it will look very familiar to you. You can either run configurations manually or you can use one of the predefined default configurations. So, typically you'd run a make and then specify the name of the default config set up for your target hardware. Building is just as simple as running make. And then once the process is completed, you will find that you have your files ready to deploy in the output images directory. So, that can be either a tab or an image kernel bootloaded depending on what's been specified for your target. And then, final stage is to test it will deploy. So, in my case, this was tested with QMU, but it could be that stage that you copy your files to a SD card or memory device for your target board and then run. Okay, we'll start with the first step and get hold of the source code. Straight forward to show you there, just to clone the Git repository. On my machine, it was less than 30 seconds to check out. And on the disk, the total size of build route was 136 megabytes of code. I did actually, as a parallel process, run the same exercise through with the Yocto RISC 5 meta layer. And initial say, there were similar sort of sizes for the initial amount of code. Configuring, this is what you get if you run a make menu config once you've checked out build route. So, it's very straightforward. Menus up and down, you select options. So, on the left, you have the top level menu showing you the high level choices of tool chains, kernels, packages, bootloaders, etc. And then the screenshot on the right shows what you get if you select target options, gives you some choices for RISC 5. So, you can actually select the different architecture extensions for RISC 5, so that's showing the general purpose. But if you want to individually specify that you've got atomic, floating point, multiplication, etc., you specify those. Next stage, building a system. Just as simple as running make at the command line. On my system, we're talking 22 minutes from start to completed build. Kernel came out with BBL wrap around it, 6.5 megabytes. And the minimal root file system, 3.9 megabytes. The figures I had for Yocto were marginally larger but comparable. And once it had finished downloading and doing a full build on my system, there was about 2.9 gigabytes of space on the disk, whereas the figures I had for Yocto were about 10 times that. It was about 30 gigabytes after I'd run a Yocto build to give you an idea. Okay, next stage on to testing. So, the incantation at the top was what I ran QMU with. So, you can see running with the QMU virtual machine, you pass it a kernel specifying the BBL image file, and in this case, pass it a root file, a separate root file system image as a drive. And you can see there that it's boots right down to a build root login prompt. A quick run through of ongoing tasks and things that I need to be looking at in the future. Firstly, I've got work to do on 32-bit support. 32-bit support and patches have been accepted into the build root repository recently, and it currently builds 32-bit for QMU, but some work needs to be done to look at for the version of Glib-C currently for building other packages. The screenshot you can see on the right, there is the output you get from the build root auto-builder test system. So, as part of the process, I need to work down through those. It highlights for you running continuous builds and produces a report of targets and packages and issues, and you can go and look down at the build root and configuration logs. And it's part of the ongoing process to work through that now both RIS5 64-bit and RIS5 32-bit. Next thing to be looked at really is to look at trying, as I said, trying to migrate as many features as possible to use upstream versions. So, I really need to start looking at whether I can migrate to the mainline kernel and also sort out 32-bit Glib-C so that I can take out custom repositories from the build root configuration and everything at upstream source. There are other features that I'd like to look at adding to build root, especially as the RIS5 ecosystem evolves. I would like to look at U-boot particularly as to get that into a more sort of standard boot loader and add features to that for particular boards. And also as software libraries and other C libraries become available to add those as well and increase the amount of options available. One thing that we don't have at the moment of course is support for particular development boards. So, we've only got the QMU default virtual configuration at this precise time. So, as more boards come out, it would be good to add default hardware configurations for the new boards as they come onto the market on GitHub there where you can go and see an update as to what the status of the various ports and packages are for the RIS5 ecosystem at the moment. I've done a very quick overview. A very high-level view. I'm happy to take any questions. Well, as I've said, at the moment, we're doing parallel work for customers on RIS5 targets and systems. So, I think from my point of view, as I said, it represents a good in-house tool to provide a tool chain and to provide a way of testing applications that perhaps I'm not using build root for the customer, but I want to write and cross-compile an application to run and test on their system. So, I think really as initially as a system, I mean hopefully we will get customers who come along and perhaps want us to add build root support for their particular board and generate an upper system, but at the moment it's kind of an in-house, I see it as an in-house tool, really, to make that available. I've had a brief look at the Freedom USDK. Parmel may be able to help with these things. There is a version of build root that sits down underneath the Freedom USDK. I believe it's a couple of years behind the current build root. And when you look at the configuration, it is very minimal in terms of not being able to specify any extensions or options in terms of I don't think you can specify the ABI or the things. So, it's possibly could do with a...  I've used both systems, and I think that in my experience, I think they're two different systems for two different applications. I think build root, as I said, is perhaps good for a one-man project for getting a system up and going. Perhaps a slim down system, I don't know whether Yocto easily produces, you know, smaller libraries, quick and fast systems. I see Yocto as adding a more powerful system that you might want. I think it's partly my background in smaller boards, lower resource systems. I see very much build root is sitting towards that end of the market, and Yocto sitting perhaps for more powerful applications, more flexible systems that need more features. So, I mean, you'll find a lot of talk on the Internet about comparisons between the two, and I think they are two different bees for two different things. Does that sort of help? It does help, I mean, because I never really spent any time with board support. Yes, I mean, I think, of course, there's sort of corporate backing behind Yocto in terms of board support layers, and some of the members that provide that sort of backup for board support packages. But I think it really depends on the type of system you're trying to produce, and maybe the number of people you have working on your project. The cousins of build root, there's also OpenWRT, which originally came from, and there was an announcement a few months back on the first release of OpenWRT, the pre-alpha release of OpenWRT for Rix 5, and together with Autana, just left, I did a Docker wine liner that takes this QMU wrapper, and just have, when you run it, you have a shell, and then you can install packages because the problem with build root and Yocto is that, correct me if I won't, you don't have any packages, package manager. You build everything and it's one... Yocto's package manager. Package manager, yeah, yeah, yeah. But with root, you don't have. No. You have to recompile again, and a little bit of flexibility. I think that's one of the advantages of Yocto. A partial upgrade rather than a full system deploy, so that's another choice there. I mean, as I said, coming back to resource limits, systems I've worked on haven't really ever had the overhead to have a full package manager and database down on the target, so I've worked with things that need to be quite slimline in that regard. Anybody else? Nope. Okay, thank you very much.


السلام عليكم ورحمة الله وبركاته إذا كنت تحب شخص جديد من رمضان ورحمة الله سأقوم بعمل هذا الشهر يمكنك أن تساعدنا على أسئلة at www.amu.org سأقوم بعمل هذا الشهر إذا كنت تحب شخص جديد من رمضان ورحمة الله وبركاته الحمد لله رب العالمين والصلاة والسلام عليكم ورحمة الله وبركاته نبينا محمد وعلى آله وصحبه أجمعين هذا الشهر هو شخص جديد من رمضان ورحمة الله وبركاته وما فعلناه هو أننا نساعدهم معهم ومجمعهم إلى أسئلة أسئلة ولكن من الناس who asked this question مع هؤلاء who asked about someone who is very old who isn't necessarily sick but they are very old are they exempt from fasting someone else asked about type 1 diabetes and there were others who asked about a seher and el-waswasa about magic and about whispering from the shepan so what I wanted to do is to amalgamate these questions together and bring it into a single question about those that are exempt from fasting so we're going to come first of all and we're going to mention a few different statements of the scholars in this regard so that we can get an idea of what the limits would be in terms of what sicknesses are an excuse for breaking the fast and what aren't and then insha'Allah we'll come to try to summarize it in a simple way insha'Allah for everybody so ابن قدامة in his book المغني رحم الله تعالى he said he said the sickness which allows a person to break a fast or not to fast is that which is strong it's شديد it's severe the one that will get worse through fasting or whose recovery would be slowed down because of fasting so we can see from this that there is a it's not every kind of sickness it's not everything and then he mentioned from أليمام أحمد that he was asked about fever and he mentioned that أليمام أحمد included fever in the things that were permissible to break the fast for so we can see that it's not every kind of sickness and we're going to come to some examples of that and he also said and he mentioned another category he said he said he said the healthy person who's scared that they're going to become sick so here we're dealing with another side to the another side to the to the مسألة and that is a healthy person who today when they started the morning the morning came and they're healthy but they fear that if they fast they're going to become sick and it's not an irrational fear but a genuinely they have a sickness like for example diabetes or something like that where if they fast they fear that they will become sick he said that that is the same as the sick person who's fear who fears getting worse those two are the same and now in his مجموع he also he also mentioned المريض العجز عن صوم he mentioned the person who is sick and unable to fast لمرضن يورجاز واله لا يلزمه صوم the person who he thinks he's going to get better it's not a permanent sickness that person doesn't have to fast but here and you know he mentioned he mentioned here إذا لحقه مشق ظاهرة بالصوم he said this has to be a clear harm in this person fasting there has to be a clear hardship and a clear harm in this person fasting he said الذي لا يلحقه به مشقات ظاهرة لم يجز له الفطر بلا خلاف عندنا he said the person who has a very small sickness that really isn't any great hardship for that person to bear it's not allowed for them to break their fast and there is no disagreement in this issue among us among the there is no difference in this example and رحم الله تعالى he gave some examples of the sicknesses which are very mild and which you can't break your fast for he said the sick person who doesn't actually get affected by fasting he gave an example of having a cold or a mild headache or a small amount of tooth pain he said that person is not allowed to break their fast so we've understood from this that the issue of the person fasting the sicknesses we can divide them into two categories those sicknesses which really are easy to manage with fasting a person can manage it you have a headache you could have a headache the day you're not fasting also if it's mild we're not talking about the severe migraine that a person desperately needs to take a painkiller for it but we're talking about a mild headache a mild cold a person who just doesn't feel very good on the first day that they fast or one of the days that they fast maybe they miss the صحور and they feel a bit hungry and they just feel a bit ratty and irritable these are not permissible for a person to break their fast for what is permissible is that which is شديد it has a degree of severity it has a degree of seriousness and which it has مشقة in it it has hardship in it for the person who would wish too fast and we can link that to the statement of Allah when you read when you read Allah wants things to be easy and not to be difficult so we understand that someone who's coming to physical harm extreme harm is hospitalized or the person is going to die because of it or they put in their health at risk in a serious way that person shouldn't be fasting they shouldn't be fasting and they shouldn't be kidding themselves and telling themselves that I should be fasting that person they shouldn't be fasting and likewise the person who has that mild illness or mild conditions that person should not be breaking shouldn't be breaking their fast so here we can categorize some categories here we can bring and summarize and talk about some categories we can say the sickness which is going to get significantly worse or the cure for it is going to become significantly delayed that's one example of a sickness that you should not fast with one that is going to get worse or one in which your cure is going to be significantly delayed we're not talking about get worse like you have a headache and you fast and it gets a little bit more but it gets significantly worse or the delay is significant the second one is that which there is there is great hardship for the person to fast in that situation and the third one is when a person genuinely feels genuinely feels that they will become sick and we're not talking about about false ideas and false concepts but somebody who has a real medical reason to believe that they will become sick with a sickness which is serious if they were to fast if they were to fast and that's why here the scholars they don't require necessarily that it is a shot for the person to go to the doctor but many times in the fatawa of the scholars you see that they advise the people to go to the doctors and ask them and this is important because even though we don't make it a condition and we don't say that it's a condition for the person and we don't find in the books of the Fouqa Ha'a that they made it a condition that a person must go to the doctor and get a permission like a signal but what we would say is that many people struggle to categorize whether their sickness is really going to is really affected by fasting or it's really serious or it's really going to get worse so in this case they should go to the doctor but in this I would give you one piece of advice which is I would advise that you are careful if you do have to go to a non-muslim doctor because a non-muslim doctor it may not understand how important it is for a Muslim to fast and they may say oh it's better for you not to fast I don't recommend for you to fast we don't think you should fast when really they don't actually have the way to measure up the importance of fasting versus the sickness so I think it's better if you do go to a non-muslim doctor you would it like that and you say to them will I come to physical harm or will my sickness become significantly worse if I were to fast am I going to come to significant harm or significant difficulty if I fast or is there a way I could change my medication or change my situation so that I would be able to fast and if the doctor says no I'm sorry that's not possible then Alhamdulillah the person has done what is obligatory upon them as for the one who is suffering from it was worse then my advice in this regard is not to decide for yourself because the one suffering from is seher and muscle gin being possessed by the gin and the similar kind of sicknesses the shey plan has a degree of hold over them and that degree of hold over them or influence over them it could lead a person to go away from obedience to Allah because of what the shey plan the shey plan tells you it's hard for you to fast you can't fast so my recommendation would be this decision should not be made by you rather you should discuss how you feel with a person of knowledge who knows your situation and knows your sickness perhaps if you have a Iraqi or someone like that who is observing your case or even if you don't and you have someone of knowledge in these cases who can look into your situation uniquely and advise you because I fear that a lot of people who have waswas the shey plan will tell them not to fast and make them feel as though they can't fast when in reality the only one that would come to harm is the shey plan and if we look at the issue of the sicknesses being those which are going to delay the cure or the cure is going to become delayed rather we feel the opposite the one who has waswas was seher al-mas this person it is believed and hope their cure will speed up through fasting not slow down through fasting and there remains one issue because type 1 diabetes was mentioned and type 1 diabetes is a kind of sickness which is one of the things the scholars talk about المزمنة the sicknesses which don't get better usually speaking generally speaking they're sicknesses that don't get better and in this a person is not required to make up the days because they can't make up you can't make up any days if you believe that it's it's not likely you will ever be able to fast so you can't then make up the days so what you have to do is you have to feed a poor person نسفة صار half of a صار you could measure it at one and a half liters or many of the scholars said that you can approximate it at one and a half kilograms and here there comes another question which a person might ask which is that if I believe that I have a sickness that can't be cured let's say type 1 diabetes and I believe it it's not going to be cured and then what happens is later on I receive some experimental treatment or I go to a different doctor and I realize that I can fast I take a different kind of insulin or I have a different kind of tablet or a different kind of injection and I realize that I'm able to fast then in this case what do I have to do so in this the scholars differed over 3 opinions and it seems to me that the correct opinion is that the person does not have to make up those fast from before but they only had to have paid the video for it that's enough if they paid the نصف صعب for every day that they didn't fast then inshallah after that when they're able to fast again they fast inshallah so we hope that has answered the question with regard to the kinds of sicknesses that a person is exempt from fasting 4 and Allah عز وجل knows best والصلاة والسلام على نبينا محمد وعلى آله وصحبي أجمعين


Mobile banking is at the top of the list. There's an expectation because of how we all live our daily lives with our smartphones and our tablets that engaging and interacting with the business is going to be able to be done over the mobile platform. So it puts a set of requirements on the development teams and on the testing teams and on the management teams. I also think it does ratchet up the expectations that you iterate more quickly because we're all used to our smartphone apps. I think every other time I log into my smartphone, I've got 25 new app updates. And yeah, these are consumer applications, maybe a new speed or a game, but it's permeating the mindset of customers out there. So yes, we're seeing that significantly impacting the way that we deliver.


What's the best way to measure blood pressure in surgical patients with obesity? While oscilometry, using blood pressure cuffs, is the standard, in patients with obesity, these may not fit well, and oscilometry only provides intermittent information. Arterial catheters provide continuous monitoring but are invasive and can cause complications. One alternative is using a non-invasive continuous finger cuff method, but little is known about how these various methods compare in obese patients. A new prospective study published in the journal Anesthesiology has found that in patients undergoing bariatric surgery, there was better agreement between intra-arterial measurement and the finger cuff than with standard cuffs for mean arterial pressure and diastolic blood pressure. And with standard cuffs, forearm measurements were superior to those on the upper arm or lower leg. The researchers evaluated the different types of blood pressure monitoring in 90 patients with a mean body mass index of 48 who underwent bariatric surgery. At six points during the surgery, the team recorded the mean arterial pressure and systolic and diastolic blood pressure with a radial artery catheter, which served as the reference, and with a finger cuff and a classic cuff used on the upper arm, forearm, and lower leg. The finger cuff measurements were fairly close to the intra-arterial measurements. For mean arterial pressure and diastolic blood pressure, there was better agreement between the intra-arterial reference and the finger cuff than with any of the standard cuff measurements. In an error grid analysis in which experts set risk zone boundaries to see whether the therapeutic interventions triggered by measurement differences would be of high or low risk, the vast majority of the differences between finger cuff and intra-arterial blood pressure measurements were of no or low clinical risk. While the absolute and the trending agreement between finger cuff blood pressure measurements and the intra-arterial reference were only moderate, 99% of the difference occurred in no risk or low risk zones. The oscillometric readings did not agree as well with the intra-arterial reference, although the forearm measurements were superior to those from the upper arm or lower leg. This is a new finding and suggests that the forearm may be used in surgical patients with severe obesity when using the oscillometry method, although more research is needed before making this a general recommendation. The success of the finger cuff also suggests this newer technology is a reasonable alternative to oscillometric blood pressure monitoring in surgical patients with obesity.