WEBVTT 00:00.000 --> 00:19.000 The working, Mac is fine, on time, okay, welcome, thanks for staying so late for the last 00:19.000 --> 00:20.000 session. 00:20.000 --> 00:26.200 So today we speak about hardware at the moment, specifically the 8th gen free, welcome 00:26.200 --> 00:28.200 from SOC. 00:28.200 --> 00:32.880 So first, introduction, who am I? 00:32.880 --> 00:40.000 So I've been hacking the kernel for the last 20 years, actually we maintaining and contributing 00:40.000 --> 00:46.400 at the time for the last 10 years, so I could do a bit quite a lot of commits and only 00:46.400 --> 00:49.400 a few weeks and a few weeks as well. 00:49.400 --> 00:57.200 And freshly member of the project led to a team committee of a year boot since we joined 00:57.200 --> 01:05.400 SFC, last December, I'm Lino Rokana, like us, for the last three or three years and that 01:05.400 --> 01:07.400 took kids and forgets. 01:07.400 --> 01:09.400 So I'm really busy. 01:09.400 --> 01:17.360 We kept two years ago, I was atleast them, and I presented the state of welcome managed 01:17.360 --> 01:28.640 support on 85, 50, 80K, running bus mega to S, and it has a few half edges, but it worked. 01:28.640 --> 01:34.080 At the time I posted, I showed the support of the agent free, which I posted the patched 01:34.080 --> 01:40.640 I two months ago, three months ago, most of it was marriage and working, and only the 01:40.640 --> 01:46.200 advanced figure was making me sing on the list to be posted. 01:46.200 --> 01:53.160 So when I upstream staff basically, I really want to make it usable for people and for 01:53.160 --> 02:01.480 product because pushing staff upstream, which is useless and not working, not interesting. 02:01.480 --> 02:10.040 I did a lot of work on AM logic SOC, now it's super stable, and we have some SBCs, we can 02:10.040 --> 02:16.720 run mainland Linux, and basically can take any major distalk for debyan, fedor, or whatever, 02:16.720 --> 02:18.880 and put it directly without any change. 02:18.880 --> 02:23.560 So I hope we will be able to do the same with welcome SOC. 02:23.560 --> 02:29.240 We're going in this path, but it's not yet here. 02:29.240 --> 02:37.440 So let's speak about the SOC, the agent free, or the 8650, or the LANI, the program naming 02:37.440 --> 02:42.280 is complex, but it's the same stuff we've been about. 02:42.280 --> 02:50.680 So the list, it was two years ago, high-end SOC, but it's still very powerful, and still 02:50.680 --> 02:52.680 is about the platform. 02:52.680 --> 02:56.320 Qualcomm is the insinit as a gamut platform now. 02:56.320 --> 03:08.360 So it has basically 8 cores, a 750GPU, available for decoding capabilities, out of DSP's, 03:08.360 --> 03:18.000 IOS, IOS, and a nice storage speed, like the UFS4, GF5, only Qualcomm ships this. 03:18.000 --> 03:26.280 So we have all the diagrams, which is actually fascinating, but yeah, nice to have. 03:26.280 --> 03:31.840 So what today, what is date of support, after two years of work? 03:31.840 --> 03:42.240 So every major feature of the SOC is supported upstream on Linux master, including GPU, 03:42.240 --> 03:50.400 camera, UFS, PCI, USB-C, complete with PD, and alt mode, then OJox mode, the thermal 03:50.400 --> 03:55.680 stuff, DSP, or the compute, and modem, and OJJSP. 03:55.680 --> 04:04.320 And events spend regime, which is quite a feat on Qualcomm ships, and crypto charters. 04:04.320 --> 04:10.480 And we are working on advanced stuff, so there is work on progress for this SOC, but 04:10.560 --> 04:17.800 overall, because everything is shared between all the chips in Qualcomm world. 04:17.800 --> 04:25.480 So we are working with the advanced display support, camera support, which is, you 04:25.480 --> 04:37.080 have, we have combination of sensors and files, advanced encoding and encoding, and advanced GPU features. 04:37.080 --> 04:43.360 So the journey of the upstreaming, because it's not easy, Qualcomm ships are super complex, 04:43.360 --> 04:49.960 there's a lot of subsystems, which has really much more complex than other vendors. 04:49.960 --> 04:53.600 So let's speak about hardware. 04:53.600 --> 05:04.160 First, what helped here was the small shift with the previous generation of SOC, which 05:04.160 --> 05:09.920 was the 8550, which was the high end three years ago. 05:09.920 --> 05:16.640 And most of the hardware is similar, which means we have small bumps, small new registers, 05:16.640 --> 05:18.640 but overall is the same. 05:18.640 --> 05:27.520 Except the biggest key point of the SOC is the GPU, the core layout, like no more arms, 05:27.520 --> 05:34.520 which I'm 42, finally, and the NPU, which is a separate stuff, it's still. 05:34.520 --> 05:41.120 And all of the drivers are really similar or it's still the same. 05:41.120 --> 05:49.600 So it helps a lot to bring up new devices, and for this case, it was really helpful. 05:49.600 --> 05:57.200 And it was like a work of 12 or 12 hours of work of people to trap this possibility. 05:57.200 --> 06:07.560 So, on day one, four years ago, I helped push support for the 8550, so on day one, 06:07.560 --> 06:16.000 we had Boutu Art, just right, because it was the first time we managed to put you art on day 06:16.000 --> 06:19.000 one on the Qualcomm chip. 06:19.000 --> 06:25.120 And on two years ago, I did the same, but Boutu UI, and day one I pushed all the patch, 06:25.120 --> 06:35.120 to Boutu UI, and I even ported past my catOS in secret, basically, which it was a premar catOS. 06:35.120 --> 06:43.760 So, the overall change was this 59 patch that, and I did statistics, and only had to change 06:43.760 --> 06:50.200 to patch that, basically to revisions, why took me six months, basically to all the stuff, 06:50.240 --> 06:56.880 cleaning, all the bindings, all the check, check patch, and verify everything, everything is 06:56.880 --> 07:04.360 is a companion correctly, but yeah, so it's doable. 07:04.360 --> 07:11.200 One of the big hardware support on Qualcomm SFC is Power Management, which is one of the 07:11.200 --> 07:19.480 biggest features, because it's able to go low in Power Management, and so this is the biggest 07:19.560 --> 07:25.800 part, because more than system chips, basically, it doesn't have any best anymore. 07:25.800 --> 07:36.680 Yeah, sorry, we take it and then, so, more than chips don't have any best, basic best 07:36.680 --> 07:42.720 anymore, because they have what we call network on chip, so it's multiple network on 07:42.720 --> 07:49.560 chip, like Ethernet Twitch, so between component of the system, you have packets from 07:49.560 --> 07:57.400 flowing, and you need a central point to configure these network on chips, and on Qualcomm 07:57.400 --> 08:03.160 SFC, you have on the recent one, you have a thing called RPMH, which is a coordinator, 08:03.160 --> 08:10.520 and a voting management, between all the systems, because different systems of the 08:10.520 --> 08:20.720 SOC, like the GPU, DSP, and ISP, they all can all vote for their own resources, so you 08:20.720 --> 08:27.360 have a central resource management that will vote for the system network on the chip, 08:27.360 --> 08:33.800 interconnect, for the voltage, the power domains, the regulators, and the memory controllers 08:33.800 --> 08:34.800 bandwidth. 08:34.800 --> 08:42.960 So, it makes really things hard, so most of the resources from Linux, we don't directly 08:42.960 --> 08:52.040 speak to the, don't write to the registers or speak to the PINIC, we speak to the RPMH, 08:52.040 --> 08:58.240 and it makes really power management challenging, because we don't really know exactly 08:58.240 --> 09:07.720 if our vote will be taken in account for thermal reasons or speed-building reasons, we 09:07.720 --> 09:14.000 don't know, so it's hard to achieve low, very low consumption, so Qualcomm does it on 09:14.000 --> 09:21.480 Android, because they really develop the kernel, and all the system features for that, 09:21.480 --> 09:26.280 but to support it in a generic way, it's super hard, and the hardware is to support the system 09:26.280 --> 09:33.880 for our collapse, so it's super low power in SSPAN mode, so we manage to have it on some 09:33.880 --> 09:44.440 laptop that we have a super hacky-way, the GPU, then a big subject, so most of the work 09:44.440 --> 09:50.280 is in your space, that's really in the kernel, thanks to EGAIA, so if you have time, 09:50.280 --> 10:02.040 look at the XDC torque on turnip, which was done on this XAT GPU, the GPU on the STAT XC50, 10:02.040 --> 10:09.360 the biggest thing in the Qualcomm GPU is the GMU, so basically like the new NVIDIA GPU 10:09.360 --> 10:16.040 as well, you have a firmware set, it does all the power management stuff, it does all the 10:16.080 --> 10:22.760 clock management, the voting performance, leg app image, basically when you want to run 10:22.760 --> 10:31.240 a task on the GPU, you will ask the GMU to change the performance level, so it will 10:31.240 --> 10:38.000 handle directly all the stuff, again you need to have a firmware, so it's, it can depend 10:38.000 --> 10:48.480 for the phones, for example, one complex stuff, it's speed-binding, so on some recent chips, 10:48.480 --> 10:55.040 they change the way, they expose speed-binding, before you have a simple number, you will 10:55.040 --> 11:01.280 map to a bit map to a specific level, now they want to, we will address a lot of markets, 11:01.360 --> 11:09.040 like gaming plus phone and so on, so as I added two values, you can combine to make a bit mask 11:09.040 --> 11:15.760 and we don't support it because it's super difficult to complex, so this is something we need 11:15.760 --> 11:22.640 to tackle to be able to achieve the high frequency on some devices, like the gaming SOC, which 11:22.640 --> 11:32.080 has a higher speed-binding than the phones, for example, and the freedom driver, so it's quite 11:32.080 --> 11:41.680 the old driver, but it was updated for the A7 GPU, which is with the variants, can arise from 11:41.680 --> 11:47.520 the A6 GPU, it is a difference, it's a GMU, but since it's a firmware, we don't fully see 11:47.520 --> 11:54.960 the difference, we have to speak the same variant of the protocol, we added a few features on the 11:54.960 --> 12:04.080 last two years, you will close the gap with Qualcomm KGSL grab, and we still have some working 12:04.080 --> 12:13.520 progress, like the speed-binding, or the L pass L pack, which is a specific way to run a lot of 12:13.520 --> 12:26.080 latency compute, let's talk about the DSP XM DSP, so basically in the Qualcomm chips you have 12:26.080 --> 12:32.480 and the balance of the systems for the DSP, so usually you have the IDSP, the application DSP, 12:32.480 --> 12:40.400 that runs all the applications, that links with use, like the audio and USB-CPD battery, 12:41.200 --> 12:50.080 you have the CDSP where you can run compute task, and the modem is also at the XM DSP, 12:50.080 --> 13:00.800 and on the phones, when it's run with the Qualcomm bootchain, you simply need to authenticate 13:00.800 --> 13:07.200 the firmware and run it, and it's completely independent, you don't need to do anything to make 13:07.200 --> 13:15.280 it run, and then you have a shared memory and mailbox communication, and you can have all the 13:15.360 --> 13:21.920 services exposed by the firmware, you can directly use, like for example, the audio path, 13:23.120 --> 13:31.360 the USB-PD, and modem, so this is how we can support all the USB-C features, and 13:32.800 --> 13:39.760 send source support for this, as you see, is working progress, I don't know, they change a lot 13:40.480 --> 13:48.720 since the old phone, like 11.6, it's a complete change, or the protocol, so I think nobody 13:48.720 --> 13:53.920 ever looked at this new version, hopefully one day we have the sense of source. 13:54.880 --> 14:07.600 Consection display, so these phones, basically all the Qualcomm phones, chips, share the same 14:10.240 --> 14:16.160 display engine, which is basically they can configure the different level planes, 14:16.720 --> 14:22.480 and a different number of old put, so it's super scalable and an extremely comfortable, 14:22.480 --> 14:30.000 so it makes the driver really complex, the number of blocks is not so hard, but the way they can 14:30.000 --> 14:38.800 interact makes an integration of the air, and really, really complex, so the common usage we do is 14:38.800 --> 14:46.400 the SI and DisplayPort, and it's functional, and we black with the support for the very advanced 14:47.200 --> 14:53.520 features they're using phones, for example phones, phone displays can be super complex, because they have 14:55.520 --> 15:01.440 kind of DC common mode, where can they, they can put dynamically, the display, interior, 15:01.760 --> 15:12.880 fresh, and makes the range right dynamic, so all these is not super tele Linux, there's no 15:12.880 --> 15:19.600 actual any support anywhere to support like dynamic range change right, the building or the 15:19.600 --> 15:26.800 application, so this is the feature we'll need to add at some point, and like DisplayPort DSC and this 15:26.880 --> 15:35.680 is the DisplayPort, it's a multi-pull display on single to different planes, it's still working 15:35.680 --> 15:45.360 for us, but it's supposed to work on phone chips as well, the VPU, so like I said, they have really 15:45.360 --> 15:52.800 a powerful VPU, so you can decode and code up to 8k, I think it's super like 24 concurrent 15:52.800 --> 16:02.480 decoding encoding, so it's really impressive, but it's stateless, but initially we had the venues driver 16:02.480 --> 16:12.000 which supported the old generations, but quite a change protocol for this new SOCs, which is much 16:12.000 --> 16:19.520 more aligned on how VPU defaulted to M2M and to M, and also the buffers, so they started to 16:19.520 --> 16:27.680 robot it entirely, which is I mean we were skeptical at the beginning, but they did a good work 16:27.680 --> 16:34.720 to basically reduce the driver to the minimal support, only decode stuff on reference platforms 16:34.720 --> 16:43.840 and add all the new features entirely, it worked quite well today, I mean so we happy because 16:43.920 --> 16:51.600 it was really well tested at each aspect, I mean everything was properly done, but the main 16:51.600 --> 16:56.160 gotcha is a firmware, because the introduced plenty of different ways you sign the firmware on the 16:57.120 --> 17:04.800 other different new platforms, so it's not easy when you have a platform which is signed differently 17:04.800 --> 17:14.000 for example the phone or tablet, there is a camera system, it's the last biggest system, 17:14.000 --> 17:22.000 this one is the most difficult, because basically it's a huge system and welcome 17:23.040 --> 17:29.840 use canics, which is basically a distributed computing system running in your space 17:30.800 --> 17:41.120 because ISP is super huge, and in upstream we have to import the minimal set to get data from the 17:41.120 --> 17:49.920 sensor, it's called KMSS, so it's basically a DMA, but I mean it's a DMA, but we have it, we can 17:49.920 --> 17:55.840 get data from the sensor, but we need to handle all the sensor mode sensor data in your space 17:55.840 --> 18:04.960 or in GPU, which is depending on the platform quite an important task to you on the CPU GPU, 18:08.000 --> 18:13.280 but thanks for leap camera, we can do it, so not on the phones are not fully 18:13.280 --> 18:20.640 problem, but it's more on the laptops, we need to use all the camera management in GPU, 18:21.120 --> 18:33.200 so there's another big thing in the Qualcomm SSI's boot order, boot order, the boot, 18:33.200 --> 18:38.880 Qualcomm boot floor, the use to boot Android, because it's a main goal to boot on these 18:39.440 --> 18:50.880 chips is PBRXBL, Genia, ABR Linux, basically they implemented XBL, which is like a 18:50.880 --> 18:58.240 BIOS that bought BFI, it's something a beast which is super extensible, you can configure with the 18:58.320 --> 19:07.600 best is stuff, and it has a UVU-FI core, only to load ABL, which is Android Budada, which then 19:07.600 --> 19:14.960 disables aFI and you boot Android, so most of the time you never use aFI on these platforms, 19:15.520 --> 19:25.840 you will only use a ABL in fast boot, but we can enable a EFI on some platforms, 19:26.720 --> 19:32.640 so we can all almost make it work in a PC and boot, we're almost like, so 19:37.360 --> 19:48.000 but like you said, we ported your boot on Qualcomm chips to replace to fill the gap, 19:48.000 --> 19:53.520 when you only have ABL, you can have change it, you can boot your boot as an XPOS EFI, 19:54.240 --> 20:01.600 so we ported all the major drivers for UFS, PC Express and USB, and we are working as a display 20:01.600 --> 20:09.040 as well, and we can expose a proper UFI, I mean UFI you can fix, because Qualcomm, UFI has some 20:09.040 --> 20:14.880 bugs, and you can fix them, so you need to go on them, with your boot you can fix them, you can 20:14.880 --> 20:19.440 extend them, and you can support advanced feature like the UFI capsule, for example, 20:20.400 --> 20:28.400 and we could even replace ABL with it, but we're still working progress, so we need to work on it. 20:32.720 --> 20:41.280 So products, there's a lot of chips of device that run on this chip, so you're plenty of 20:41.840 --> 20:48.640 found your tablets, you have gaming device, because Qualcomm is innate as a gaming chip, 20:49.600 --> 20:59.920 and there's one device in particular that was done like late 2025, which is 20:59.920 --> 21:08.160 quite an expensive device, it's like eight hundred euros, but it's running this chip, 21:09.120 --> 21:16.080 and it's unlocked, there's no secure boot, you can replace ABL everything, and it's really based on 21:16.160 --> 21:22.800 the Qualcomm reference device, so it would be easy to port and support, and I'm added to run with 21:22.800 --> 21:30.000 only a few patches on top, so you can see it without the height sink, there's nothing 21:30.000 --> 21:40.720 particular to see, actually, and I ported it to Postmark that was, and it's merch, and thanks to 21:41.200 --> 21:46.000 and thanks to a guy who did the initial port and helped me finish the port, 21:48.480 --> 21:56.800 so and thanks to the email to Postmark ABL, which enables the EFI boot, so I can just boot 21:56.800 --> 22:03.120 Postmark at OS, we see them in the boot, via a key, we weren't no user data to leak or whatever, 22:03.120 --> 22:09.120 so it's super cool, so let's do a live demo of the device, 22:09.840 --> 22:18.160 so no deal of demo, I mean, I'm running the device, I'm directly, so you can see the Postmark at OS 22:25.120 --> 22:37.600 and you can open play game, to fame us, what does it work, okay, so it's running well 22:37.600 --> 22:47.120 can, went by fault, we've missed our main line, so I got you all, I mean, 22:49.840 --> 22:53.360 so it doesn't work, but yeah, we got things working, 22:59.200 --> 23:05.440 let's switch back to the slides, and I just don't want to, okay, so I can show you over games, 23:05.440 --> 23:22.080 and you can show me your main test, if you want, so the device, we'll talk about, I mean, the 23:22.080 --> 23:26.560 team that did the GPU support, what you work, what you were, I mean, it's really impressive because 23:26.640 --> 23:34.800 the device is really snappy, and I didn't have any issues with the graphic, hopefully, 23:37.840 --> 23:54.000 I'm being again, so let's conclude now, I'm going to put in three steps or the good in this 23:54.000 --> 24:02.960 last year's experience is the support for how many solids is not really easy to see how it's 24:02.960 --> 24:08.560 solid, but when you've bought a device which is so complex like this and it's so easy to 24:08.560 --> 24:18.000 port in fact, it is solid, the fact that most of the hardware features are shared between the 24:18.000 --> 24:26.720 devices, means we get fixes and new features for free by porting the new generation, for example, 24:27.360 --> 24:35.360 which is nice, Qualcomm did a lot of course recently to fix, and at really complex new drivers, 24:35.360 --> 24:47.120 we couldn't actually support, and WSD is high, I mean, I spent like a week to take the device 24:47.200 --> 24:54.720 ported buzz the patch and put it in buzz market OS in a single week, which is really fast. 24:56.720 --> 25:02.880 So the bad, as the firmware stuff is really hard, he made it make a percussion hard, 25:05.280 --> 25:12.720 I'm used to not push them out, it's changing, they pushed GPU from wires and GPU from wires 25:12.800 --> 25:18.640 for a lot of chips recently, which is good, but it's not, it's far from good because we still 25:18.640 --> 25:28.320 miss a lot of GPU and WBFMRs, there's a problem with the percussion testing, the device 25:28.320 --> 25:34.480 are not tested regularly and not enough in your next or some regations are detected very late 25:34.480 --> 25:40.800 and fixed to late, as the rate you get to fix upstream is too flow, 25:41.520 --> 25:49.680 thanks to Beyond, there's no change yet, and the ugly is, we support the SOC, very well, 25:49.680 --> 25:56.000 but we support almost no device completely, we lack a lot of support for devices, 25:56.560 --> 26:05.440 speaking with different audio, IR key, different display topology and so on, so it's okay to support 26:05.440 --> 26:10.880 SOC and the switchers, when we need support more actual implementation on the device, 26:11.840 --> 26:18.080 and so we support, we lack a lot of features, we don't support because we don't have the device 26:18.080 --> 26:25.520 upstream, like also display camera, the low power stuff is somewhere in the DSP, so 26:27.360 --> 26:32.880 it's it's fully usable on mainline, when you are currently, you can find 26:33.840 --> 26:40.640 external device, like I know I know Pocates do, which is not secured, so you can replace ABL, 26:40.640 --> 26:47.120 you can enter it flash it, it's a give all the files to flash it from scratch, if you have 26:47.120 --> 26:53.920 flash you can, if everything in a flash you have thing, and any cheaper, and easier to buy than 26:53.920 --> 27:03.440 the hardware, the HGK, for example, so if you have HSS 50 device, pick a device, build a T, 27:04.160 --> 27:12.720 and subline patches, and if you need some help, we are on IRC, in SMSM, or we can join people in 27:12.720 --> 27:27.120 the Pocates, thank you, so if you have quick chance, 27:27.120 --> 27:45.680 you can use some pre-company devices, but you can only do anything about it, or if there, anything 27:45.680 --> 27:54.480 to look out when you buy a device, no, I don't have any, if the question is, how about the 27:54.560 --> 28:04.400 device, I completely loved, I don't know anything about that, we don't use any HSS 50 phones, 28:05.440 --> 28:12.880 so I don't know, maybe ask people, like Pocates do, or OS, they, they,