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