 Dweud am ymddangos ar y cwrs mewn gael. Ond yna Yw York wedi gafodd yng ng saus ymlaen hyn o ddefnyddio L'Fffff-F-P-S-D a'r L-M-F-P-S-D yn ymdangos i allu cyfnod i ni'n gweithio eu cyflenau ar yי publishio ar y roi gyfer hyn. Rhaid, mae'n eitihon o rhywfaint o'i cyfnod i fynd i ddwyllwch yn L-M-F-P-S-D so that the workshop runs smoothly. So a bit of background, there's a series of, there's a group of electronic engineers based around London who run various events and back in 2013 they decided that they were going to run a workshop on Verilog for programming FPGA. And we started with what were these introductory boards from Altera and using the proprietary closed source toolchain for learning Verilog and this workshop was just an absolute disaster. It was over a weekend and the first day we basically just spent the entire day trying to get the toolchain to install. The problem is is that there is no open source alternative and you're stuck with this toolchain and you have to kind of get it working. They provide you with this four gigabyte download which uncompresses and installs to about 13 gigabytes of multiple versions of Pearl, Tickle and various modules that go with it. So we spent the best part of the day trying to get this to install and then when we actually started doing the exercises and went to synthesize we realized that some of us had actually installed the licensed version and not the free version and you would have to go back and reinstall and start again. The reason I'm saying this story is because it made me realize that actually in some cases the tools are kind of mandated and you have no choice whereas in our case we're an open source project and we can change things. Move forward a few years on I was invited to give a talk about the BST family of operating systems to the same group of engineers basically and why it would benefit them for running BST on their hardware. At that event I kind of took a more generic approach and represented all the BSTs and about a month or so a few months onwards I was invited to actually come and do a workshop and I've never run a workshop before and my skills of teaching are non-existent so I decided that I would actually just focus on one BST and try to make that run smoothly. So I picked an FBST to do that. Just as I forgot to switch board slides. So the other thing that actually came out from that FPGA workshops is the guys two of the guys went on to actually setting up an open source FPGA board with an FPGA toolchain so you don't have to inflict this on other people ever again. Yes this is true. So I've most of these people who are turning up are actually not interested in the software itself but what it can actually do for them. So my idea was to basically raise their expectations of what they should expect from an operating system which we can do because we're a fairly mature project, fairly well documented, have fairly decent practices in place and it was also very enlightening that things that we are of concern to us don't really hit the ball for them. So mentioning that we don't have system D just doesn't register whereas obviously it's a pain for most of us who have to suffer it and I thought that I would basically the angle that I would take it is this is how you can save time trying to do your projects and these tools will allow you to do that and kind of develop that for them. So traditionally if you want to kind of get involved with the BSDs there's quite a steep learning curve in terms of the amount of text that you actually have to take in to become proficient in actually just how things are put together and I didn't really want to kind of go down that line. I wanted to kind of find all the bits from a very high level that would allow me to demonstrate how they could save time and avoid digging into any of these technical details because most probably they're not actually interested, I'd probably do a bad job at it most likely as well and you should be able to kind of do some things without actually having to resort to the internals. Interesting thing that's actually come up in the past a couple of weeks is this new hashtag called unqualified for tech where people are talking about you know the senior roles that they have without the academic backgrounds on Twitter which is it's nice to see. So you quickly realise that most of these folks have to kind of suffer really brittle tools to get their job done. Like one thing that was quite enlightening for me was the way that we generate project files for our bootloader for Windows CE. We have this orc file which generates our visual studio configuration file which you can load and you can build. If you make the slide is adjustment in one pixel from the user interface environment visual studio will corrupt that project and that's it you can't make any progress it's kind of obviously we don't have to suffer this but I'm sure there's been many hours man hours lost by people trying to work with visual studio. Things like Brendan Gregg's, I'm not sure if I'm going to be able to do that but I'm not sure Gregg's shouting in the data centre video which showed the ability when you have really rich tools to shout at a bunch of j-bods and through the instrumentation tools in your operating system be able to see actually what impact that had. Most people don't have this in their day-to-day work as a researcher by the name of Brett Victor who gave us talk about rich tools and the example that he was giving was when you're developing a game going from trying to work out the correct setting for a value to set for your environment you know in relation to gravity to being able to see that change dynamically in real time to being able to project where you're going to go so it goes from how did I end up here to what am I actually capable of to where can I actually end up going and the last one Brian Kentrill did a talk back in 2009 about the early days of detrace and how that came about where they had a son e10k that they'd sold to a customer and it was misconfigured and it would crash and it would take another 45 minutes for the system to come back up again so when you're actually trying to develop something or debug a problem a 45 minute turnaround is quite a serious time sink so and there's enough examples of you know really bad tools that people have to kind of suffer and that manifests in kind of really weird behaviour which I guess which was kind of touched on in at the opening keynote the amount of windows users that you know live in fear of having to restart because you know suddenly your machine is going to go down into this long update cycle to shut down and then there's going to be another two or three reboots again when your system comes back up you know not doing updates because you don't know what's going to actually happen when you update and especially like in firmware the system is so brittle that you can't actually explore any ideas or like in the network world where redundancy is a licensed feature you're really scared to change anything because if the system goes down you can't do anything about it and I think most of these things are just a non-issue for us in the in the bsd world and especially in the net bsd project so as I said focus on basically how how net bsd can make someone's life easier and ignore the system internal details to keep it really high level and just make sure that the process is really smooth so we can go through it without actually having to sidetrack so these are the topics that I decided to kind of cover demonstrate that our system is fully documented and well not fully documented but the documentation is available and easily browsable maybe in the era of github it's not so important but demonstrate that the history in the source repository is readily available and you know the free bsd project has the csrg history that you can kind of go back and explore the cross compilation stuff that makes it really easy to do things without having to run the the target environment locally actually explore the internals what explore the system with lure do some things with rump explore the the simulation devices like the gpio sim and then I look at kind of tamper resistance with very exec so we had this problem in that we generate images but the images you can't log into on the network as standard because root doesn't have a password you know you can't log in so at the moment the requirement is that you need to have a serial adapter to go in and connect the problem with that is is for the linux users you kind of get sidetracked into installing a ucp package so you can get cu and have to kind of sidetrack into changing file system permissions which kind of people get lost at I'm not sure if this is still the case on the latest version of osx but in the older versions you would get unsigned kernel extensions which would mean people would have to kind of fiddle around with their EFI settings and turn off signing the nice thing is is actually that one thing we do do is we have multicast DNS enabled as a standard for our arm images so discovery on the network is really easy but we don't have means of log it in on on the network yet but I that's my target so that you'd end up just writing the image plugging it into your device booting it and then sshing in so some of the kind of issues that were kind of evident immediately was when we came into doing like the cross compilation stuff the autocom scripts for the various components that we pack were out of date so the notion of you know 64 bit windows running segwin just wasn't a thing the arm image that we were generating wasn't actually bootable on the the beagle board that I was actually experimenting on the GPIO driver wasn't actually working properly which paul helped me paul guilty helped me fix and most of the arm boards that we support has a generic kernel configuration and everything is a derivative of that there were some cases specifically in the beagle bone black that it was actually on a kernel configuration of its own which meant that certain options weren't enabled which I didn't actually find out until we came to the lesson and somebody was actually having to do extra work that didn't need to be done because the pie users had the relevant parts and the last one which is still yet unsolved is broken u-boot scripts now in u-boot it's very much like a linux project in terms of there's various support support for various platforms but the inconsistency is there in terms of ti have contributed a bunch of changes for adding an extra configuration file for your firmware which one family of boards have picked up on and another family of boards do not have which means that we can't actually have a consistent configuration file and the reason this is a problem is that because we have two different steps one ends up overriding the other in the order of execution and it means that we're trying to execute a kernel that doesn't work on the beagle bone so since that stuff has started since this has started Mark made various changes to the lua subsystem in the PSD he bought lua up to date and he had some things in his github which I'm not sure I've made it in yet Jared McNeill made it very easy for us to ship u-boot he created packages and it's trivial to add new images now literally two or three lines in a make file and we have new firmware to do I need to kind of my idea is to basically create a kind of a worksheet that so people can just work off easily so that's still on the to-do list provide better lure and rump examples the reason I kind of wanted to do the demonstrate the rump mechanism to the to the engineers was because there was a blog post by anti about how he developed the Intel wireless driver and being able to pass through a device to the rump environment and develop develop that the thing is is that actually trying to demonstrate that you need to actually have quite a lot of context set up about the system internals because you need to turn around and say you need the following subsystems to instantiate so that it works correctly and that kind of goes off in a different tangent so I'm trying to think of an easy example that would kind of work without having to you know explain explain that oh you need to find mount a file system you'll need the vfs module and x yn z as I said implement mechanism to add users for network access the way that we provide our images we have a DOS partition and Jared had this idea of maybe we could just create a text file with a username and password and then when the system boots up that text file is read and the user is created so that it's available when the system is up but yeah I haven't explored the options. Unify the uboot script so actually addressed this issue of having a single file which deals with all the boards that we support rather than having this split across multiple platforms. Mark Balmer created this lure binding called UNIX which provides some of the common sysquals for the OS and I'm guessing that was on the to-do list to make it in but maybe provide something around that to show that you can actually interact with the system without having to resort to writing C and just from yesterday's Cherry's talk perhaps maybe an ATF and Anita example to show how you can do tests but my only concern is that you'd kind of go off into dealing with Kimu. Yep so my thanks go to Mark Balmer for doing the lure, lure subsystem, Paul Goethe for helping me with the bug fixes, Nick with making the images bootable long arm, Jared for uboot and no thanks to Jared for uboot it's true it's not his fault entirely. The London Hackspace where I kind of worked on most of the stuff and open source hardware user group where I got to present run these workshops and the next one is going to be next Saturday in Oxford at the Oxford Hackspace so hopefully yeah this will kind of continue running that's it any questions uh just a little suggestion um it may be easier to have people installed putty than uh um the CU. Ah that's true yes um even on but the the CU is on for Linux ah okay I didn't I didn't realize I thought it was still a Windows thing so anecdotally um I've heard from several people that they have like one or more armboards in the drawer and it's was just too frustrating to get uh like NetBeats it over us to get anything booting on them so you know they're sitting in the drawer um so I think I think you could um get a lot more arm users if there was a simple and working how to for a couple of the most um often used of these boards I think. One thing I should mention is um the testament to the cross compilation framework in FBSD it was basically um the other thing that we address is that we don't we're not inflicting a foreign environment to them as the offset you know they're really sitting in their own environment that they're comfortable in would be at Mac OS or Linux we've had a couple of people with Windows but they've kind of had different problems and yeah it's really easy to get up and going um I didn't actually end up running a full release as part of the workshop because obviously uh varying speeds of laptops you know you're not going to be able to turn a release around in a short time but we can actually do um build a toolchain and build a arm kernel in less than uh 15 minutes on a modern laptop and that just works smoothly for Windows 10 there's uh there's been different problems and that's just been you know one user hadn't been on the up-to-date builds so it didn't have like the linux subsystem and another user had the linux subsystem but it was buggy so when he started you know on compressing stuff the system just crashed and rebooted. The situation with the arm boards is improving as well one of the biggest issue was always finding the correct u-board version for the board and that's being worked on with the packages and also the FDD support makes it easier to get a working kernel for your board without having to compile it yourself and things like that so but I fully agree that the documentation still needs a bit work to make it easier. I think the like the u-boot documentation is just it's so user hostile again. One remark about the serial console on linux on your versions you might have to disable modemd. So modem manager or whatever it is called so basically uh someone in the pertering land decided that all serial devices are obliciously modems and they always send some some AT sequences to it to try to get it to talk back and it's especially annoying if you're dealing with FPGAs you want to program but it can also mess up uh any other use of serial console so this is just a service announcement uh be warned. In that case thank you very much. Thank you.