[00:00.000 --> 00:12.880]  Hello, and welcome to my open source firmware status on AMD platform's presentation.
[00:12.880 --> 00:18.080]  My name is Mihał Żegowski, I'm a firmware engineer from 3MDep, we are based in Poland.
[00:18.080 --> 00:25.680]  I'm a corporate guy, mainly developing support for various platforms, mainly inter-platforms.
[00:25.680 --> 00:37.000]  I also maintain the Brasswall SOC, PC Engine's platforms, I'm also at the open power system software technical workgroup chair.
[00:37.000 --> 00:45.120]  And I'm basically playing with open source firmware since 2017.
[00:45.120 --> 00:54.000]  For those who do not know 3MDep, we are in various places, like we're corporate license service providers, we're UFI adopters,
[00:54.000 --> 01:05.000]  we also provide FWPD, the firmware update project consultation services, and also we do some Yachto stuff.
[01:05.000 --> 01:11.160]  So, a little bit of information that I will use throughout the presentation about the micro-architectures.
[01:11.160 --> 01:22.000]  So, in previous years I have been talking about various older platforms as well, like for PC Engine's APU-1, KGP-D16, APU-2,
[01:22.000 --> 01:32.280]  and those are the old micro-architectures called Puma, Baldoser, Piledriver, and so on.
[01:32.280 --> 01:44.960]  So, I have based on some sample platforms so that you can sort of imagine what I'm talking about if I mention some platforms.
[01:44.960 --> 01:51.120]  And there are also the newer mobile SOCs from the Ryzen series, which are supported by Corbwood.
[01:51.120 --> 01:55.080]  This is Picasso and Cezanne micro-architectures.
[01:55.080 --> 02:00.280]  These are the newer APU series from the Zencore architecture.
[02:00.280 --> 02:08.960]  And also we'll be talking about the newest developments like the Mendocino, Phoenix, and Glindasox.
[02:08.960 --> 02:16.800]  Not that they could be previously known as under different names because the original, the target names were actually embargoed.
[02:16.800 --> 02:25.960]  So, you may have heard of Sabrina or Morgana, SOCs as well earlier, that were being developed for Corbwood.
[02:25.960 --> 02:32.600]  So, those have changed the names to the Mendocino and Phoenix.
[02:32.600 --> 02:44.000]  So, to review the last year's status, we had Picasso and Cezanne development quite complete,
[02:44.000 --> 02:48.960]  but there was no FSP yet for the Cezanne, but this has actually changed.
[02:48.960 --> 02:53.440]  The FSP was published in September last year.
[02:53.440 --> 03:03.480]  There was also a development of the PSP firmware, AAB partition recovery, supporting the AMD-AVW tool in Corbwood.
[03:03.480 --> 03:12.520]  So, one of the patches was merged, and the single one that I linked above is probably duplicating the functionality.
[03:12.520 --> 03:20.640]  So, the whole AAB scheming stuff is used for any recovery in case of corruption of the first partition,
[03:20.640 --> 03:28.320]  or if the memory configuration after some changes in the setup application would make the system unbootable,
[03:28.320 --> 03:38.120]  then the PSP can, for example, switch to the AAB partition and still be able to, for example, initialize the memory and boot the platform.
[03:38.120 --> 03:44.520]  There was also an effort to implement the PSP firmware extraction with the same tool,
[03:44.520 --> 03:46.600]  but it's still not merged.
[03:46.600 --> 03:57.880]  It seems that the activity there quite stopped, and there's no further work continuation for this feature.
[03:57.880 --> 04:02.160]  Yeah, and I mentioned last year that there were new patches for the Sabrina SOC,
[04:02.160 --> 04:09.520]  so the Sabrina has changed the name to the Mendocino, I believe.
[04:09.520 --> 04:20.640]  And yeah, I said that in 2021 there was another negative attitude towards the old AMD platforms that were like entirely open
[04:20.640 --> 04:25.000]  with full source code for the CPU initialization.
[04:25.000 --> 04:30.760]  If you'd like to see more details, please refer to the Corbwood leadership meeting minutes or the mailing list.
[04:30.760 --> 04:35.960]  I'll also be talking about it also later in the presentation.
[04:35.960 --> 04:48.640]  So in 2022 we also had many new features and option deprecations with each release.
[04:48.640 --> 05:00.240]  Those deprecations sometimes causes the platforms to drop out from the master branch and they are moved to the stable branch.
[05:00.240 --> 05:15.560]  These new releases tend to move the whole Corbwood drivers and code quality to the higher level by replacing the old interfaces
[05:15.560 --> 05:24.960]  that were, for example, buggy or had some kind of assumptions that made some old platforms, for example, boot.
[05:24.960 --> 05:31.520]  But they were hiding some small errors because of those assumptions.
[05:31.520 --> 05:37.880]  So it is necessary to bring these new interfaces to the old platforms as well,
[05:37.880 --> 05:45.800]  but sometimes there's not enough time or resources and hardware to test everything,
[05:45.800 --> 05:54.320]  so some platforms naturally will be moved to the old branches.
[05:54.320 --> 05:59.000]  But thanks to the companies like PCNGs and a few Corbwood developers,
[05:59.000 --> 06:05.440]  certain platforms get the required support and the new interfaces are implemented.
[06:05.440 --> 06:11.440]  So the platforms like PCNGs APU2 is still in the master branch,
[06:11.440 --> 06:17.160]  but some other boards were unfortunately dropped.
[06:17.160 --> 06:23.440]  So another year came with new Corbwood releases, as I said,
[06:23.440 --> 06:28.400]  and many old AMD platforms were actually dropped.
[06:28.400 --> 06:38.080]  To those platforms we can count PCNGs APU1, some MSI, MS7721, Lenovo AMD G505S, etc., etc.
[06:38.080 --> 06:45.120]  That is a little bit unfortunate to see, but there was a lack of actually any testing or
[06:45.120 --> 06:56.560]  maintenance that could also bring those platforms to the newest code, despite our sincere efforts.
[06:56.560 --> 07:03.040]  So we tried our best to actually implement the new interfaces and we sent patches quite
[07:03.040 --> 07:16.960]  early, it was in May 2021, but the problem with reviewing the old code is that there
[07:16.960 --> 07:22.960]  is not enough understanding how those old AMD platforms work, because the initial code
[07:22.960 --> 07:31.160]  that landed to Corbwood was in kind of maybe proof of concept quality and was depending
[07:31.160 --> 07:39.760]  on the EGISA code that was published by AMD, and it was not in the best quality.
[07:39.760 --> 07:46.920]  So if something didn't work there, it was hard to actually locate the bug on the Corbwood
[07:46.920 --> 07:55.440]  site, and there were also promises that the code will be maintained, will be cleaned up,
[07:55.440 --> 07:57.040]  but it didn't really happen.
[07:57.040 --> 08:06.080]  So this burden of maintaining those old platforms were shifted to Corbwood developers.
[08:06.080 --> 08:15.880]  So through all those years, the code didn't improve that much, so in such circumstances,
[08:15.880 --> 08:22.160]  the platforms will slowly naturally die, and on the Corbwood master branch, it will be
[08:22.160 --> 08:29.720]  shifted to the branches created during each release.
[08:29.720 --> 08:34.800]  We tried to save one of the old platforms, which is the KGP D16.
[08:34.800 --> 08:41.360]  We have sent over 50 patches that implement simply the first booting stage of Corbwood,
[08:41.360 --> 08:49.200]  so this is just the beginning, but already the mess of code is enormous, and we lacked
[08:49.200 --> 08:56.960]  the reviewers to actually process all those patches, so yeah, this is pretty hard to maintain
[08:56.960 --> 09:02.600]  those old-ending platforms, because like I said, there is very little understanding
[09:02.600 --> 09:07.040]  how all those platforms really work despite all the documentation.
[09:07.040 --> 09:15.600]  So Intel platforms are like more straightforward, I would say, at least for other developers.
[09:15.600 --> 09:17.600]  That's how it is.
[09:17.600 --> 09:24.120]  Okay, about the new SoCs.
[09:24.120 --> 09:30.600]  So in this season, development has been stabilized, there are many Chromebooks running on it,
[09:30.600 --> 09:36.920]  and we even have seen two non-Chromebook platforms that have been actually sent for review by
[09:36.920 --> 09:39.680]  the starlabs.
[09:39.680 --> 09:47.240]  These two laptops, unfortunately, cannot be built without the blobs, or can be built,
[09:47.240 --> 09:52.920]  but it will not produce a functional image, because certain PSP blobs that are required,
[09:52.920 --> 10:00.680]  for example, for the memorization, cannot be there due to the NDA stuff and so on.
[10:00.680 --> 10:05.800]  So this is something that also needs to be solved.
[10:05.800 --> 10:11.960]  But all other components are actually in place, and you can track those patches and see what
[10:11.960 --> 10:12.960]  is its progress.
[10:12.960 --> 10:21.040]  As I said, AMD, Mendocino and Phoenix are quite new architectures that are being developed
[10:21.040 --> 10:29.240]  in an upstream core boot, while the Mendocino is quite in a more advanced state than Phoenix,
[10:29.240 --> 10:35.960]  Phoenix is a newer one, and FSP is not published for those micro-architectures yet.
[10:35.960 --> 10:43.480]  You can also notice some PSP blobs that are present in the AMD blobs repository.
[10:43.480 --> 10:54.240]  AMD glint dies like the newest micro-architecture that has seen the sunlight.
[10:54.240 --> 10:57.800]  There is practically no information about that in public.
[10:57.800 --> 11:04.480]  It may be also an burgled code name, so it may change in the future, and I do not have
[11:04.480 --> 11:07.120]  much else to say about that yet.
[11:07.120 --> 11:15.560]  But regarding the blob situation, so the Starlabs could build the firmware for their laptops,
[11:15.560 --> 11:21.640]  and probably boot core boot, but they cannot publish the necessary blob that is provided
[11:21.640 --> 11:28.720]  by the board code to initialize the memory, because each design may be different and requires
[11:28.720 --> 11:33.640]  different configuration, how the memory topology looks like on the given platform.
[11:33.640 --> 11:40.400]  So you have to provide that by the board code, and this becomes the problem, because Chromebooks
[11:40.400 --> 11:48.440]  have only soldered down memory, and there is no support, for example, to build the blob
[11:48.440 --> 11:54.000]  with memory configuration for a platform that has solding modules, for example.
[11:54.000 --> 12:01.320]  I believe this is the main reason why this cannot be built to a functional image, core
[12:01.320 --> 12:03.320]  boot image.
[12:03.320 --> 12:09.320]  On the PSB, all the PSB blobs and FSB is present in the AMD Blobs repository.
[12:09.320 --> 12:12.800]  You can check its license on the repository.
[12:12.800 --> 12:14.080]  It is quite permissive.
[12:14.080 --> 12:23.600]  It allows the redistribution, so similar to the Intel FSB and microcode licenses.
[12:23.600 --> 12:29.000]  And of course, you cannot decompile this assembly, et cetera, et cetera.
[12:29.000 --> 12:36.480]  We've also took a quick look at the FSB release intervals, and these are quite delayed, I
[12:36.480 --> 12:37.480]  would say.
[12:37.480 --> 12:44.520]  For example, between the FSB for Picasso and the CISAN, there is one and a half year of
[12:44.520 --> 12:48.760]  distance in the initial commits on the AMD Blobs repository.
[12:48.760 --> 12:56.680]  And for example, the CISAN FSB was released one and a quarter year after the launch of
[12:56.680 --> 12:58.200]  the processors themselves.
[12:58.200 --> 13:01.680]  So as you can see, the delay is quite huge.
[13:01.680 --> 13:07.200]  For Intel, I would say it is like a few months or half a year after the initial release of
[13:07.200 --> 13:09.600]  the CPUs where the FSB is available.
[13:09.600 --> 13:18.240]  So it is like much more stabilized ecosystem for Intel, but FSB for AMD is quite a new
[13:18.240 --> 13:19.240]  invention.
[13:19.240 --> 13:26.080]  I would say it's like maybe three or maximum four years old, while FSB is like for over
[13:26.080 --> 13:33.320]  seven years or so on the open-source firmware market.
[13:33.320 --> 13:40.000]  Regarding the server platform status for AMD, nothing much happened here since the last
[13:40.000 --> 13:41.000]  year.
[13:41.000 --> 13:48.080]  Like, we had those initiatives, for example, from Google Romantic that showed the AMD,
[13:48.080 --> 13:56.280]  Rome and Milan proof-of-concept Linux boot or bootstaff, but nothing else happened.
[13:56.280 --> 14:05.880]  On the recent OSFC 2022, which was in September in Sweden, there was also something new, similar
[14:05.880 --> 14:08.880]  to what Romantic showed.
[14:08.880 --> 14:14.840]  So Brian Cantrell from Oxide showed some proof-of-concept of their firmware on AMD
[14:14.840 --> 14:21.720]  Blan, which was also based on Linux bootstaff, but they had implemented some bare initialization
[14:21.720 --> 14:28.200]  of the PCI Express so that the storages and other IO could also work.
[14:28.200 --> 14:30.040]  It was all very, very basic.
[14:30.040 --> 14:42.200]  So nothing close to what you would normally see in the UFI from independent BIOS vendors.
[14:42.200 --> 14:48.480]  So to summarize up, what is actually the future of the AMD platforms in Corbett?
[14:48.480 --> 14:53.320]  So for sure, the Chromebooks will be gaining the support.
[14:53.320 --> 15:00.880]  They are backed by Google cooperation efforts, they have partners, they have Corbett developers
[15:00.880 --> 15:08.200]  working in AMD, and their partnership will make the project successful, for sure.
[15:08.200 --> 15:15.920]  But for such old platforms like KGP or all the models that I mentioned that were dropped,
[15:15.920 --> 15:22.080]  it's pretty difficult to actually keep them in the main tree, and it requires significant
[15:22.080 --> 15:24.960]  effort to actually maintain a board.
[15:24.960 --> 15:34.360]  So either there must be a community that is willing to test Corbett images on their devices,
[15:34.360 --> 15:42.440]  but on the second hand, who is brave enough to flash their daily laptop and possibly break
[15:42.440 --> 15:45.360]  it, because something didn't work.
[15:45.360 --> 15:51.760]  So it is also not for everyone.
[15:51.760 --> 16:01.960]  Also the quality of the initial code that was published for those old platforms, it was
[16:01.960 --> 16:09.520]  just getting older and older, and the actual cost and the effort that would be required
[16:09.520 --> 16:16.560]  to bring it to the quality we would want is bigger and bigger.
[16:16.560 --> 16:23.440]  So while, for example, the model of dropping the silicon initialization vendor code is
[16:23.440 --> 16:27.600]  good for initial launch of the platform, because you have everything modular and you just tune
[16:27.600 --> 16:31.160]  it, in the long term it is not maintainable.
[16:31.160 --> 16:37.680]  It can speed up the platform shipment by maybe 50%.
[16:37.680 --> 16:44.440]  But in the long term, it is a burden for the project that is supporting this vendor code,
[16:44.440 --> 16:51.720]  and then we end up with such situation where the boards are simply dropping out of the tree.
[16:51.720 --> 16:58.480]  So in such conditions, all AMD boards will naturally die and will be moved to the branches.
[16:58.480 --> 17:06.040]  So we may expect further platforms being dropped out, and I think the next one on the aim is
[17:06.040 --> 17:08.400]  probably APC and APU2.
[17:08.400 --> 17:17.080]  For now, it supports all the recent interfaces, but I have no idea how long it will last.
[17:17.080 --> 17:25.640]  Also we think that the lack of strategy for the long term support by the Corbett leadership
[17:25.640 --> 17:32.360]  is largely decreasing the value of the project itself, because many people rather don't like
[17:32.360 --> 17:37.880]  their boards being dropped, because if they clone Corbett, they clone it from the code
[17:37.880 --> 17:43.120]  from the master branch, and if the issue make menu config and want to choose the board,
[17:43.120 --> 17:45.640]  they see it's no longer there.
[17:45.640 --> 17:50.520]  So basically they think, oh, it is not supported anymore.
[17:50.520 --> 17:58.560]  So this kind of value is decreased, because people will see that something is already
[17:58.560 --> 18:03.840]  not supported, and they lose their hope in the project.
[18:03.840 --> 18:12.440]  So a new strategy would be required to actually keep those AMD platforms alive in the tree.
[18:12.440 --> 18:19.720]  So what we think can save those platforms is the Shara firmware.
[18:19.720 --> 18:25.600]  We are open for any AMD outcasts from the Corbett, and we're working hard to actually
[18:25.600 --> 18:32.640]  prepare a strategy that will make these platforms support more sustainable.
[18:32.640 --> 18:39.760]  We often also disagreed on many Corbett leadership meetings with the current Corbett strategy,
[18:39.760 --> 18:47.200]  but we also offered various ideas like crowdfunding and other stuff that could potentially solve
[18:47.200 --> 18:55.120]  the problems that we were noticing, but unfortunately those were rejected.
[18:55.120 --> 19:03.600]  If you'd like, you can visit Corbett leadership meetings for more details.
[19:03.600 --> 19:06.560]  Also I have a short announcement for you.
[19:06.560 --> 19:14.680]  Unfortunately, the official PCNG's open source firmware support has been ended by the PCNG's
[19:14.680 --> 19:26.560]  company, and the 41901 was the last version that we released, and in the format we have
[19:26.560 --> 19:31.200]  been doing for the past few years, monthly.
[19:31.200 --> 19:33.960]  But do not worry, our commitment is still strong.
[19:33.960 --> 19:40.680]  We want to further improve the PCNG's firmware, but this time we would like to release it
[19:40.680 --> 19:48.600]  under the Shara branch with new features like UFI interface, DMA protection, setup applications,
[19:48.600 --> 19:53.760]  setup BIOS password, and stuff like that.
[19:53.760 --> 19:58.280]  But it will be only a community driving project.
[19:58.280 --> 20:00.480]  We will not have any funding for that.
[20:00.480 --> 20:10.560]  So your support is actually crucial in determining the roadmap and what the pace of the development
[20:10.560 --> 20:11.560]  will be.
[20:11.560 --> 20:15.920]  So I encourage you to take our survey.
[20:15.920 --> 20:18.520]  Your input is very valuable for us.
[20:18.520 --> 20:29.200]  If you have any insight or want to support us, please do.
[20:29.200 --> 20:40.520]  So to sum up, we want to make the Shara a paradise for old AMD platforms and outcasts.
[20:40.520 --> 20:45.920]  Of course, like I said, it will be community driving, so we want to make it a success and
[20:45.920 --> 20:53.200]  have community involved as much as possible.
[20:53.200 --> 21:05.520]  So what we offer with the Shara is we're ready to go test at binary releases with transparent
[21:05.520 --> 21:07.520]  validation.
[21:07.520 --> 21:12.040]  We publish all the test cases on our documentation page.
[21:12.040 --> 21:15.680]  You can use our hardware and software tools.
[21:15.680 --> 21:22.000]  We have validated and used daily during the development, which can help you in case of
[21:22.000 --> 21:26.160]  any recovery or even deployment of the firmware.
[21:26.160 --> 21:33.240]  We also provide high-quality documentation, which explains every caveats and procedures
[21:33.240 --> 21:40.360]  for the updates or the deployment and recovery of a platform.
[21:40.360 --> 21:45.720]  So if you want to know more, please feel free to sign up to the Shara newsletter to get
[21:45.720 --> 21:49.560]  up-to-date information about new features, our releases.
[21:49.560 --> 21:59.720]  So you may also find the new initiatives and new projects that we plan on the Shara documentation
[21:59.720 --> 22:09.200]  page, so I encourage you to visit.
[22:09.200 --> 22:13.720]  Of course, I will gladly talk more about the AMD platforms because I'm pretty much short
[22:13.720 --> 22:17.360]  on time here and cannot explain every small details.
[22:17.360 --> 22:25.880]  So if anyone is interested, we can go later in the evening for some beers and talk a little
[22:25.880 --> 22:27.880]  bit more.
[22:27.880 --> 22:34.520]  We can think on the first matrix or we can join the Shara matrix as well, where we are
[22:34.520 --> 22:36.480]  more responsive.
[22:36.480 --> 22:43.720]  We can just come up with some good place, I think, and talk a little bit more.
[22:43.720 --> 22:48.000]  The depth is also planning to hold two events in March.
[22:48.000 --> 22:53.480]  It will be the Shara user group, which is a forum of the Shara users.
[22:53.480 --> 23:01.400]  This will be a small event with more structured schedule, where we will discuss different
[23:01.400 --> 23:03.920]  topics related to the Shara.
[23:03.920 --> 23:09.080]  And right after that, we will hold the Shara developers virtual pub, where this will be
[23:09.080 --> 23:16.360]  a more relaxed forum event, where we will discuss any topic community wants and what
[23:16.360 --> 23:24.200]  is of interest of them, and feel free to be invited.
[23:24.200 --> 23:30.080]  You can see more details in the blog post I link in the slides.
[23:30.080 --> 23:35.080]  So that will be everything from my site, and I'm open for your questions.
[23:35.080 --> 23:51.080]  So I have a question actually regarding that PC engine, so after like two years and a half
[23:51.080 --> 23:53.080]  of waiting, I just got my board before Christmas.
[23:53.080 --> 23:59.080]  And I got it because it has support for Cool Booth, but I thought that the guys from PC
[23:59.080 --> 24:05.080]  Engine themselves who were actually developing the Cool Booth for their boards.
[24:05.080 --> 24:12.080]  But from what you're saying, that it was sponsored for somebody else to building the Cool Booth,
[24:12.080 --> 24:13.080]  right?
[24:13.080 --> 24:18.080]  Okay, so the question was who was actually developing Cool Booth for PC Engine's platforms.
[24:18.080 --> 24:25.600]  So PC Engine's company was responsible only for producing the hardware and distributing
[24:25.600 --> 24:35.840]  it to the users, and the initial support was being developed by a company called Eltan.
[24:35.840 --> 24:43.080]  But then they requested, they shifted the Cool Booth work to Fremda, so to us, and we
[24:43.080 --> 24:53.200]  were like maintaining and improving, releasing the Cool Booth binaries each month since 2016.
[24:53.200 --> 24:57.200]  So it was like our efforts for all those monthly releases.
[24:57.200 --> 24:59.200]  Okay, theory?
[24:59.200 --> 25:08.200]  I understand that Corboud is not building the runs directly to test the platforms.
[25:08.200 --> 25:11.200]  So the burden is on the users to build stuff.
[25:11.200 --> 25:20.200]  Do you have any insights for facilitating testing in the future to prevent the boards from being dropped?
[25:20.200 --> 25:24.200]  Yeah, so the question was whether we have a strategy for the boards being dropped because
[25:24.200 --> 25:28.200]  it is users' burden to build and test the runs.
[25:28.200 --> 25:36.200]  So like it was written on the slides, we are still working on the strategy for long-term
[25:36.200 --> 25:39.200]  sustainable support for old AMD platforms.
[25:39.200 --> 25:45.200]  But we want to shift the burden to build the runs from the users and instead provide
[25:45.200 --> 25:51.200]  tested images, at least tested what we can test in our environment, in our laboratory.
[25:51.200 --> 25:59.200]  And if someone still has some issues or have some future requests, we encourage to create
[25:59.200 --> 26:05.200]  issues on our GitHub, and then we are considering what is the problem, what is the case, what
[26:05.200 --> 26:10.200]  is the cause of the problem actually, how to solve it, and we try to narrow it down and
[26:10.200 --> 26:13.200]  include possibly the fix in the next release.
[26:13.200 --> 26:19.200]  But of course, as I said, if it is community-driven effort, the pace will depend on the support
[26:19.200 --> 26:20.200]  level.
[26:20.200 --> 26:24.200]  So if somebody is able to contribute in any way, for example, fix the code themselves,
[26:24.200 --> 26:32.200]  or let's say provide the logs or flash our, for example, testing binaries to check or
[26:32.200 --> 26:37.200]  gather more information because we may not necessarily have the exact hardware configuration,
[26:37.200 --> 26:46.200]  then it may be the right step to make users less burdened with all those troubles with
[26:46.200 --> 26:50.200]  flashing and breaking stuff.
[26:50.200 --> 26:51.200]  Okay.
[26:51.200 --> 26:53.200]  Any more questions?
[26:53.200 --> 26:54.200]  Okay.
[26:54.200 --> 26:55.200]  Maybe.
[26:55.200 --> 26:56.200]  Okay.
[26:56.200 --> 26:58.200]  Let's change a little bit.
[26:58.200 --> 27:21.200]  Yeah.
[27:21.200 --> 27:27.200]  So the question is, what are the state of the patches?
[27:27.200 --> 27:33.200]  And why actually there is a problem to get the old AMD boards upstream?
[27:33.200 --> 27:41.200]  So like I said, this code is very old and it was in very bad quality, committed initially,
[27:41.200 --> 27:45.200]  with promises from AMD for the maintenance ship, which didn't happen.
[27:45.200 --> 27:52.200]  So with each year, the code just was getting older and older, and people who actually knew
[27:52.200 --> 27:59.200]  about it are no longer a part of Corbett or are they just simply retired or out of business?
[27:59.200 --> 28:06.200]  And basically, there's very few people that can actually understand what the given code
[28:06.200 --> 28:11.200]  does and actually give some meaningful review for those patches.
[28:11.200 --> 28:20.200]  So that is why it is very difficult to get something upstream for such an old AMD platform.
[28:20.200 --> 28:22.200]  Okay.
[28:22.200 --> 28:24.200]  In theory.
[28:24.200 --> 28:28.200]  You said that all your platform can be in a different branch.
[28:28.200 --> 28:33.200]  The branching model, is it like model-based or is it like version of Corbett-based?
[28:33.200 --> 28:41.200]  Let's say that some patches were made for TGP16 to be able to fix what is missing to be upstream.
[28:41.200 --> 28:46.200]  Would it happen like in the branch that is, for example, for the 11 until it reached the
[28:46.200 --> 28:50.200]  point of being back to master, how is it working right now?
[28:50.200 --> 28:53.200]  Okay, so the question is about the Corbett branching model.
[28:53.200 --> 28:56.200]  How does it work and how to apply patches on them?
[28:56.200 --> 29:04.200]  So whenever a Corbett issues a new release, so a tag is placed on the repository,
[29:04.200 --> 29:10.200]  the current revision that is tagged is being cloned into the branch and called, for example,
[29:10.200 --> 29:18.200]  4.19 branch, and these branches are in no means stale.
[29:18.200 --> 29:27.200]  So these can also be contributed to by the Garrett review system, but you have to target the specific branch.
[29:27.200 --> 29:32.200]  So even if you hook onto some revision on the branch, for example, and you want to patch it,
[29:32.200 --> 29:39.200]  it doesn't mean that in a half a year it will not have the same tree state,
[29:39.200 --> 29:44.200]  some back ported patches could be landed on the branch and then your patches that you were kept,
[29:44.200 --> 29:47.200]  for example, as a file, will no longer apply.
[29:47.200 --> 29:57.200]  So it is not like that that the platforms are just lying there with no option to improve.
[29:57.200 --> 29:58.200]  That's not true.
[29:58.200 --> 30:03.200]  You can always send patches to the previous branches as well.
[30:03.200 --> 30:12.200]  So it works like any master branch, but you have to just target the older branch with your patches that you sent.
[30:12.200 --> 30:19.200]  So the development might still be active, but it does not longer benefit from the new features
[30:19.200 --> 30:26.200]  that are basically landing on the master branch.
[30:26.200 --> 30:34.200]  Okay, any more questions?
[30:34.200 --> 30:35.200]  Yes, please.
[30:35.200 --> 30:54.200]  There's a point again for the KGBD16, which plays on port at 11. We know that that arrow, Corbou, is moving for that platform. So can we hope that the port at 11 branch involves to the point where that was more of my question.
[30:54.200 --> 31:06.200]  What can we see happening in Corbou at 11 on the nonmaster branch, but the branch that is still active for that board?
[31:06.200 --> 31:13.200]  Okay, so the question is, what can you expect on the 4.11 branch, for example, with KGPE?
[31:13.200 --> 31:15.200]  Well, that depends on the community.
[31:15.200 --> 31:23.200]  If they were to back port some patches that should land on the 4.11 branch, that is possible actually.
[31:23.200 --> 31:29.200]  But probably the older the branch, the less activity there will be on them.
[31:29.200 --> 31:47.200]  And if somebody would like to back port some features, then this is probably more efficient to do it on newer branches, because the gap is just only getting bigger and bigger.
[31:47.200 --> 32:04.200]  If anything, it would be better to work on the fork that we already have, where we rebased all the code, rewritten most of the parts that were in very, very bad shape.
[32:04.200 --> 32:17.200]  So basically, it is not impossible to have something being developed on the 4.11, but it is rather unlikely to happen right now.
[32:17.200 --> 32:25.200]  Okay, the time is up, so I can answer any questions later in face-to-face talk.
[32:25.200 --> 32:31.200]  And yeah, next presentation in eight minutes from theory about the Heads project update.
[32:31.200 --> 32:34.200]  So stay with us, thank you.