 Cool. So I'll begin. So I'm John Mason. I work for Broadcom. You know if you read the description then you know at least a little bit about me. Broadcom makes a bunch of different crap. They're awesome stuff. The best stuff only the best stuff. We only make the best stuff. So my group makes SOCs for communications. Here's the marketing blurb. You can read it or not. It's a marketing speak so I'm not sure it's actually English. And specifically I work on what we call the North Star families of SOCs. It's I don't know why we have two names but it's also called strategy X. It's part of the Iproc family so if you're familiar with some of the wireless routers that are very popular like like I think some of the ASUS ones are North Star based which is the 4708, 4709. It's Cortex A9 without VFP because that apparently took up too much real estate so you don't want that. Then we have the North Star Plus which is essentially the same thing only a little bit better and it has neon and VFP. And then our latest greatest one is North Star II which is Cortex A57 base that's ARM V8 and is used all over the place and if you want to buy some of them just let us know and we'll probably sell them to you. And then here's a that was enough marketing for me for a little bit so I thought I'd do a little little joke here. So if you don't know what a bootloader is I'm not actually going to kick you out. So a bootloader in extremely high level is trying to put the system into a sane enough state where you can boot an OS. You know you find the OS, clean up, load it into memory and boot it. You have this kind of level one versus level two. I don't want to get too deep into this because it's not super pertinent to what I'm trying to show here but the level one kind of puts it into the sane state and finds the media and then the level two actually boots it and you boot can do both and for our purposes we do use it for both. So what is U-boot? It's actually called DAS U-boot. My German is non-existent so I'm sure I'm even pronouncing it wrong but DAS U-boot the universal bootloader. I just call it U-boot throughout if you want to hear it called DAS U-boot just whenever I say U-boot just put it in your head to say DAS right in front of it. And it's a GPL V2 which I think is actually pretty significant. So U-boot can boot from pretty much any kind of media or open file system including now the network. So they've plumbed every single permutation I could think of and I looked and couldn't find anything I could actually even think of that wasn't possible. So some alternatives for U-boot the core boot UEFI or Ufi the Tiano Tiana core so this is the kind of level one level two kind of mashup because Tiano is not open but Tiana core is and you can kind of mesh them together in interesting ways. I don't want to talk about that too much except for saying that it is a popular alternative and just to be funny Broadcom also has two internal bootloader competitors because you know if you Google bootloaders there's dozens and dozens for no real reason that I can find except for everyone wants to do their own thing. So we have CFE or I think it's also pronounced cafe which is a Broadcom proprietary license if you buy junk from us apparently it's not done by my group so I can talk about it or I can't talk about it but if you buy it from us we'll license it back to you and it's mostly used in these home routers like the North Star based ones and also MIPS for the set top box group and then there's Bolt which is yet another internally developed one that's proprietary primarily used for the set top box group so just yeah there's a lot and in a perfect world we'd all be using one and maybe one day we can get there. So this is the kind of bulk of it is how to enable new hardware. So in early 2016 we got this board back this is the North Star 2 board it's in all its glory this is of course an SVK because you're not actually ever gonna buy one of these you're gonna buy like the little processor with one or two things hanging off and a printer or a NAS or something like that but when we got it back no one really cares that much about running U-boot they don't they don't even only kind of care about running Linux because they want to run their benchmarks so essentially you want to get the goal of the first one is to get out of the way to get Linux up and running as quickly as possible so that your management is not making you work weekends and you know until midnight every night because you were such a arc gating all the other kernel developers the device driver developers anyone doing diagnostics every single person around you is waiting on you to finish so that they can do their job which which is not a fun place to be so you want to be out of that hot path as quickly as possible at least I wanted to be. So step one is you need to get memory working without memory like you got nothing right. So you have RAM files your RAM needs to be admitted and and set up we luckily had a quick hack around it is because we had a fairly large SRAM built into that to the SOC so we were able to kind of bypass this and run all from SRAM. I've also been told that if you have a large enough L2 cache you can actually rejigger that to act as a temporary RAM and fit and you can hack down the bootloader to fit into there. So that is kind of that's kind of nice if you can get it but if not then then you do to have to go through but we've actually had a follow one SOC that had that did not have enough SRAM and you do have to go through and set up all this fun stuff and it is it is not fun. And this is the step two is getting the serial working because without anything going to screen how do you know that you're booting or bricked or whatever you actually need something but there is a fun backdoor. If you can get a JTAG hooked up you actually can look there is an internal print log in both you boot and the kernel if you don't have it working where you can actually see what it's been printed it should have made it to screen but didn't because the serial is misconfigured or the serial driver is broken because you have a piece of serial that it's difficult to digest and then step three get networking boot get networking working that doesn't sound like a very good run there but if you can get the kernel net booted you essentially are out of the hot path and you know but you might you're gonna need the ethernet driver and ethernet 5 you might be lucky enough from a previous generation of SOC to have those already kind of laying around or maybe minor modifications ours required more than minor modifications but there's also a secondary way if you have PCI and something like a Intel Nick you actually can use that to TFTP boot and kind of sidestep any issues that you might have there but what if you don't have ethernet or ethernet's not working on a zero or you have some kind of restriction in your lab where you can't do any TFTP or you kind of a server running or there's no network or or whatever so at least on our chips you can actually actually program the spy via JTAG which saves you a lot of foot traffic or you can use a spy flasher and have a removable spy chip and flash and move and flash and move and flash and move and that gets really tedious very very quickly and similarly if you're so see if you want to be able to reflash your SOC you actually can do the same thing but you actually need to have the drivers in you boot in place so sorry that didn't come out right so your SOC is most likely able to boot from NAND or spy but you need to have the drivers already implemented in you boot so getting that done as soon as possible actually will save you a lot of this foot traffic which is the well-born footpath here and then kind of lastly you want to you're not lastly you want to get the other peripherals running and then finally diagnostics you want to have something that can actually test your hardware kind of similar to x86 BIOS post you boot has this functionality that's actually pretty pretty well done and you might also have a marketing requirement or a requirement of other of a customer to have something stretch test your hardware but they don't want to do it in Linux because of various reasons of Linux being more having more things running in the background you want to see what the theoretical max of the hardware and things like that so you can actually run those inside you boot but a bit of caution here you can easily overflow the partition that you've set aside in NAND or spy for you boot if you don't size it appropriately or you have a very constrained amount of space which can be kind of confusing because it doesn't show up until you try to boot the secondary things like your like Linux or you might over overwrite the end of it and therefore you don't boot at all it did bite us more than once okay and how to upstream you boot so this is the part where I'm kind of a poser I apologize for that so I wasn't able to push out my patches for for for you boot until last week and therefore they haven't really been reviewed so this is kind of going to be hand waving so I apologize for that so step one is to sign up for the mailing list because the mailing list is moderated this did bite me when I did submit because I submitted on Friday afternoon and if you were not a subscriber to the list your patches wait until someone approves it and if you do it on Friday no one comes to work on the weekend then on Monday your patches will finally hit the mailing list and if Monday is a holiday then maybe or they're everyone's traveling you'll see them maybe they don't get reviewed until maybe after this presentation so if you get ahead of this and subscribe early then you avoid the stupid human error that I encountered so the upstream approach that I am taking that seems to flow with what I've seen on the mailing lists is kind of following the Linux mantra of push early push often kind of push small pieces I've seen actually a lot of full entire system supports but I think that might get a lot more review eyes to push something quick and get it in easy so the kind of Linux model of pushing small easy reviews patches each patch containing a logical change that seems to be universal and running a check patch that seems to be especially internal to my team a bone of contention that shouldn't be necessary check patch there is check patch just in you boot just like there's in Lenox there's get maintainers in you boot just like there's in Lenox that should be pretty obvious if you have a Linux developer coming to you boot to do those things and if you can somehow get this in place internally you can avoid a lot of pain unfortunately we did not have it I think this is out of order so unfortunately for us there wasn't a huge amount of customer demand for upstreaming you boot we had we got a lot of customer demand for upstreaming Lenox and getting the patches we had out of tree entry and all that but we had we had no customer saying that it would be fantastic or beneficial to you to upstream you boot so the real benefit is what you have to sell to management that by upstreaming it you do have superior code quality you have the ability to cut a software development kit on the newer version of you boot almost at will if you have multiple like a family of SOC's you have to kind of convince them that you don't want to make every single you boot a snapshot you don't want north star plus on a four-year-old version of you boot north star two on the latest one and then in four years when we do the next one to be a newer one you want to be in the newer version it's less maintenance for everyone to have everyone on the same release and they're actually so I've heard customers that actually do want everything running on the latest version and there is the possibility maybe faults or a specter that you might sell more chips if you have the enablement upstream but if they don't agree then you have to upstream after the fact which is what we're doing so you have this kind of problem of having something on the order of a hundred thousand lines of code some of which is completely unnecessary that you need to upstream so it's step one is to rebase and if you're lucky and your code is elegant you could just do a get rebase of whatever you have to the latest RC which was RC to as of Friday and it might just magically work unfortunately for us it did not just magically work it blew up in new and interesting ways and hacking it to compile cleanly and then it didn't boot and it's it's a nightmare so I took option B here is to start from scratch it might be difficult to get your management to agree or you could just not tell them some management managers are very hands-off and they might be amenable to that and then step two squash I don't think anyone and I could be wrong you people correct me I don't think anyone cares about your thousands of revisions of of an ant driver they want one version the latest version for when you push the initial version so squash get squash is get get rebase you can use it to squash it's fantastic I highly recommend it and then carving it into submitable chunks this is the approach I'm taking hopefully it is the correct one of just doing the basic enablement to taking the mantra of going small and growing it just doing the part that enables serial def config the header files in the board file then making it intelligent and adding the device tree awareness and then carving each individual driver into a separate patch and then a note to myself to add the basics of how to do that sorry about that and then finally dags and anything else for some reason some companies think that this is proprietary unfortunately it is not if you've shipped out and again I'm not a lawyer I don't play one on TV but if you've released this to a customer or somehow otherwise distributed it these things are statically compiled together you've you you are obligated by the GPL to give away this code it is no longer proprietary so yeah that might also be something to make your management aware of before they start shipping products that not they might want to do a audit of all the things they think is proprietary and making sure that they don't want to hand it out and then submit and rework this is kind of the open-source model you said something repair it until everyone's happy with it and then it goes away and then you move on to the next thing do it serially don't submit 40 drivers at once and then try to do them all at once they're all gonna have probably the same kind of problems you know reinventing the printf it seems to be a popular one or adding delays for no reason so submitting it serially and then fixing the same problem it from the first one into the subsequent one pieces is very vital I think I just blew through that so hopefully everyone has lots and questions or we can go over this patch right now so questions comments yes you're talking and tomorrow Tianokou is just the reference implementation for you we for the you if I specification from Intel and none of these require ACPI yes so we actually have a good chunk of servers right now that are running based on either Tianokou or even aim I film where that implements the UEFI specification and is running full device tree and it's all fully supported works fine yeah so the I think that the it's called the interesting part to me it is the the kind of level one level two thing because my understanding of Tianokou and I could be completely off base here is that you have the kind of basic what we would call bios in the old days basic firmware which does the setup that then launches into the level two which is the Tianokou is that my misunderstanding that or is that not true in you would speak she was basically talking about SPL and the main chunk right so Tianokou does not contain an SPL part but we also have platforms in you would which do not contain an SPL part but require some other film where to do that for us like like an ATF like and ATF sometimes does not include DRAM initiation code either okay so it if it was as easy I mean people wouldn't get it wrong right it's it's complicated but in the nutshell it's the same thing just not invented here yeah and for the people that might not be falling there there is this kind of handoff I where you have level one that hands off to level two and then you boot you actually can do I think your talk is actually talking about it being able to go from you boot to UEFI and then booted OS right I'm not gonna do my talk at this moment but basically basically you you can extend you boot with the interfaces that allow you to implement the UEFI specification so that you can run and a payload and you boot in parallel at the same time and the payload can then call back into you boot to basically implement its drivers which is what you use to implement a bootloader like a graphical bootloader not you boot which is more like a film where in the traditional PC sense of the word yes exactly so and actually on the ACPI thing again there's technically nothing that would keep you from passing ACPI tables to a payload inside of you boot either so if you wanted to I don't see why anybody would but if you wanted to you could even teach you boot how to boot a Linux kernel with ACPI tables now mm-hmm if you really like to shoot yourself in the food another remark to like where you talk about upstreaming things one thing that people keep forgetting which is very very very important is make sure your patches are always rebasable which means every single commit inside your patch set has to compile throughout so if you if you for example add a dependency from one driver to another just by like a link to a linking dependency make sure that you for example only allow that driver to ever be compiled with a kconfig entry after every connection is already there because otherwise if you do a good bisect on something different you might end up getting a dependency included for some reason one one reason or another and then your whole code basis doesn't compile anymore while you're trying to find out a bug for a completely different board all right so make sure that everything is fully bisectable those are the two I don't know that you have any thanks so the question was what is the preferred method to interrupt the boot process before booting the kernel yeah I mean there obviously is a timeout that that you can do I think the default of just hitting enter or space works with the escape key or the energy and make what's a space yeah and you can enter use a crowd like Mac address or something like that yes yes or any key thank you and of course with CFE it's control C the patches that you're submitting for you boot are they for north store in our store plus or north star 2 so what I'm spinning right now is north star 2 someone already did and it's called an alpha version of north star plus it doesn't actually boot that's not usable I think I figured out why while doing this patch so I I personally would like to try to steal time for management to allow me to upstream north star plus and north star but kind of how earlier I said you really don't want to do a snapshot in time of you boot and then walk away from it and have each SOC on its own so we have that so we have 2012 dot let's say 10 remember what exactly what release for north star and north star plus and then we have luckily we had a semi new version 2016 05 for north star 2 so okay one other quick question and that is broadcom is very difficult company to work with I don't know about working for but working with them is very difficult none of their data sheets actually tell you what family a particular processor is actually in so sometimes I'm not sure if it's north star north star plus north star 2 do you have any quick tips on that so if you can see is there an easy way sorry I think this is faster than just so you could key off that those names yeah because they'll say strategy X and it's and you don't know what it is but the SOC names the 5301 2 3 4 1 I mean the secondary numbers the skew numbers very pretty pretty drastically but the cores are pretty much the same okay another question but I'll ask you later because it's sure unless there are no more questions off the record kind of question okay yes what what peripherals you're bringing up I would strongly encourage anybody that's that's porting you to a new platform really scan through your IP it's chances are pretty good that one of those you know one of those peripherals is using shared IP that there's already driver support for excellent particular USB and USB on the go mm-hmm tend to be pretty widely shared yes agreed thank you going once twice so cool well I appreciate everyone taking the time