WEBVTT 00:00.000 --> 00:11.400 All right, good morning or afternoon. I'm not sure. Welcome to my talk. I'm going to be discussing 00:11.400 --> 00:18.920 snagboots. I'm Thomas. I work at Bootland with the Wembedo Lonex and Zephyr work. So, as a 00:18.920 --> 00:25.200 to set up to contact, most of the SOCs these days be they are more risk five SOCs. They 00:25.200 --> 00:30.880 have a run code that comes together with the chip itself and it does a lot of stuff takes 00:30.880 --> 00:37.080 here of the booting and many other things security and so on. Most of them include a recovery 00:37.080 --> 00:44.080 mechanism that allows your system to be alive even though there's nothing on your EMMC 00:44.080 --> 00:49.160 or your flash and this recovery mechanism is typically useful when doing factory 00:49.160 --> 00:53.640 flashing like when your device is really like fresh out of factory or when your 00:53.640 --> 00:58.800 development mode and you want to recover a part that is bricked for whatever reason. Typically 00:58.800 --> 01:04.480 it is run code. They work using some specific protocol that you can access over USB. You 01:04.480 --> 01:11.720 are sometimes ethernet but USB is by far the most common interface these days and this protocol 01:11.720 --> 01:18.080 usually allows you to send the case of the picture over USB. Some kind of binary payload 01:18.080 --> 01:22.680 that would typically be stored in some internal memory in your SOC and then allow you to 01:22.680 --> 01:28.960 run it and from that hopefully you can recover your system. So that's kind of what exists. 01:28.960 --> 01:34.720 And the existing situation is that each vendor provides its own tool to communicate with 01:34.720 --> 01:40.920 the SOC like NXP as its own SD as its own micro chip as its own Rochip as its own and 01:40.920 --> 01:46.360 even the one here is not the official one from Rochip that's a less horrible one that 01:46.360 --> 01:50.400 was developed by the open source community because Rochip has some Windows only tool that 01:50.440 --> 01:56.160 nobody wants to use. But one tool per vendor is really annoying. We don't have one OS for 01:56.160 --> 02:01.160 every SOC and we have Linux. We don't have one bootloader for every SOC. We have terabox or 02:01.160 --> 02:07.760 your boot. So why should we have one tool for each platform family? It kind of sucks. The 02:07.760 --> 02:12.720 venue tools are not always open source which sucks even more. And those tools because 02:12.720 --> 02:16.680 they're not open source, they're not always very flexible because they're disabled while when 02:16.680 --> 02:20.760 you're using them on the factory floor, you may need to integrate them in some way with 02:20.760 --> 02:26.640 some more complex logic that is very custom. So not having something flexible sucks. So 02:26.640 --> 02:31.480 lots of reason why the current situation sucks. So we wanted to solve that problem and 02:31.480 --> 02:36.880 this is where Snack Boots hopefully helps in solving that problem. It's like one project 02:36.880 --> 02:42.560 to rule them all. The idea is to have a vendor agnostic tool that handles this all 02:42.560 --> 02:47.520 to recover protocols. So it's a re-implementation of the tools, right? We don't need 02:47.520 --> 02:52.120 you to install the vendor tools. I was SPS today about that and it was apparently not 02:52.120 --> 02:55.920 here for for someone. So you don't need to install the vendor tools to be able to use 02:55.920 --> 03:01.920 Snack Boots. It's completely self-contained. It's open source, GPLV2. It supports many platforms. 03:01.920 --> 03:06.560 So you have the current list on the right-hand side of the slide. But we're trying to grow 03:06.560 --> 03:10.800 that list over time. We have a pull request for a rock chip support. For example, that 03:10.800 --> 03:14.360 has been pending for some time and the developer is in the room and took to me just a few 03:14.360 --> 03:19.160 minutes ago. And if you need to support more platforms, it's possible to add more. 03:19.160 --> 03:25.480 So it's GPLL license. I hope we can call it Hector friendly. It's fully implemented in Python. 03:25.480 --> 03:31.040 So it's very like homogeneous across the code base. And it has three components that 03:31.040 --> 03:35.080 I will discuss in the next three slides. Basically, it has Snack recovers, Snack flash, 03:35.080 --> 03:40.240 Snack Factory. It works on Linux and Windows. So we did the Windows part because a lot 03:40.240 --> 03:47.240 of factory floors have PC machines that run well this operating system. So it's the first 03:47.240 --> 03:53.440 time we had to buy a Windows machine at bootling, specifically for being able to do that. 03:53.440 --> 03:58.400 That was kind of an odd thing to deal with. And I have to say, I'm not the developer of 03:58.400 --> 04:03.680 Snack Boots. It's all developed and maintained by my colleague Homa. We isn't at first 04:03.680 --> 04:08.560 them, but it's the guy doing the real work. I'm just doing the talking. So the first 04:08.560 --> 04:12.760 component of Snack Boots, the first tool is Snack recover. So it's the one and 04:12.760 --> 04:17.920 link the recovery step. The one pushing, like a working payload, usually a bootloader on 04:17.920 --> 04:22.960 the target. So it could be your boot, but it could be something else. And then we usually 04:22.960 --> 04:27.880 expect that bootloader to run and then expose a USB gadget that will enable the next step 04:27.880 --> 04:34.480 which is flashing. So Snack recover needs, as inputs, a firmware, YAMO file that basically 04:34.480 --> 04:38.320 gives the pass to the different firmware files that you need to push. Sometimes it's 04:38.320 --> 04:43.120 just one, sometimes it's several. It depends on the platform, like booting flow. But once 04:43.120 --> 04:48.000 you have that firmware file, you just run Snack recover, then the name of your SOC. And then 04:48.000 --> 04:54.080 the type of your, the pass to your firmware, YAMO file, and it will do the recovery. So at 04:54.080 --> 04:58.720 this stage, your SOC is no running the bootloader that you have pushed. It's not flash. It's 04:58.720 --> 05:04.080 only running from RAM, but it's hopefully running. Then you can use the second tool. If you 05:04.080 --> 05:08.160 want to or maybe Snack recover is enough for you because the bootloader is running, you can 05:08.160 --> 05:12.720 see it on your serial port and that's enough. I mean Snack recover can be enough for for some 05:12.720 --> 05:18.320 use cases. But if you also want to flash, then you can use the second tool. Snack flash. Again, 05:18.320 --> 05:23.680 this kind of unique speedoscopy. One tool does one thing and hopefully does it well. So Snack 05:23.680 --> 05:28.480 flash has another config file, which is more like the sequence of steps that you want to 05:28.480 --> 05:33.200 run, which files do you want to flash, where on which medium and stuff like this. So one 05:33.200 --> 05:38.240 go into the details, the documentation is all the core details. And then you can run Snack 05:38.240 --> 05:43.920 flash, passing a few arguments like the vendor ID, product ID of the USB device that you want to 05:43.920 --> 05:49.840 talk with, the flash come in file, and then the back end in Snack flash because there's multiple 05:49.840 --> 05:56.160 back end. It can talk to a device that exposes the fast boot USB gadget or USB mouse storage 05:56.160 --> 06:01.120 or GFU, and it can be extended with others in the future. But do the three ones that we support 06:01.440 --> 06:07.520 today. So Snack recover, Snack flash is typically like the two sequences that you will want to 06:07.520 --> 06:14.480 run to recover and refresh your platform. And I think it was last year, a woman worked on Snack 06:14.480 --> 06:19.920 Factory. Here it's really targeted at the factory flashing use case, where you're not like a 06:19.920 --> 06:23.760 developer with a single board on your desk, but you're on the factory floor and you've got like 06:23.760 --> 06:28.320 many boards that you want to flash and you want to automate that process and make it as quick and 06:28.320 --> 06:34.560 efficient as possible. And that tools Snack Factory allows you to refresh multiple boards, 06:34.560 --> 06:40.640 you have a GUI, what the rest of Snack recovers, Snack flash is like Hiker oriented, so it's CLI, 06:40.640 --> 06:46.160 but here it's more factory floor operator oriented. With a GUI, you can see all the boards that are 06:46.160 --> 06:51.040 connected, their status, start the flashing of all the boards, it's all happening in parallel, 06:51.040 --> 06:55.360 it's state logs, and stuff like that. So it's really oriented towards flashing multiple 06:55.600 --> 07:00.480 boards in parallel. And with that, I think your convinced that Snack Boot is the way to go, 07:00.480 --> 07:05.760 and that you will download it and try it on your platform, or maybe contribute support for 07:05.760 --> 07:17.360 the platform if it's missing. Thank you very much and enjoy my time.