From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755513AbdLTPLy (ORCPT ); Wed, 20 Dec 2017 10:11:54 -0500 Received: from mail-io0-f178.google.com ([209.85.223.178]:35312 "EHLO mail-io0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755317AbdLTPLu (ORCPT ); Wed, 20 Dec 2017 10:11:50 -0500 X-Google-Smtp-Source: ACJfBouGWau6xn9G4Mv4Q2n14lQHli7Cyj93wCZCNtxplbngwmhyErQIGMxEtEkTQuWwjI/AgIq4vAhmujbDsPGV2M0= MIME-Version: 1.0 X-Originating-IP: [2a02:168:5635:0:39d2:f87e:2033:9f6] In-Reply-To: <5dc7f218-9113-fad3-c0a8-883c4bae4e02@suse.de> References: <20171213194755.3409-1-mstaudt@suse.de> <20171219161630.GI26573@phenom.ffwll.local> <2f8a1a08-911d-a511-2968-4d89418ac212@suse.de> <573d4050-7607-b8e4-7552-83966f551ba3@suse.de> <20171220094355.GJ26573@phenom.ffwll.local> <20171220101421.GM26573@phenom.ffwll.local> <5dc7f218-9113-fad3-c0a8-883c4bae4e02@suse.de> From: Daniel Vetter Date: Wed, 20 Dec 2017 16:11:49 +0100 X-Google-Sender-Auth: lVYunnZeIydq9_N_ncltaS2YWTk Message-ID: Subject: Re: [RFC PATCH v2 00/13] Kernel based bootsplash To: Max Staudt Cc: Neil Armstrong , Bartlomiej Zolnierkiewicz , Linux Fbdev development list , michal@markovi.net, sndirsch@suse.com, Oliver Neukum , Takashi Iwai , dri-devel , Linux Kernel Mailing List , =?UTF-8?Q?Bero_Rosenkr=C3=A4nzer?= , philm@manjaro.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id vBKFBx8v029816 On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt wrote: > On 12/20/2017 11:14 AM, Daniel Vetter wrote: >> btw since I'm probably sounding a bit too grumpy here: I'd very much >> support this. I think bootsplash in kernel has a bunch of uses, and it >> shouldn't be hard to get non-suse people to cheer for it (makes merging >> easier if it's not just a one-off hack). > > Thank you! > > As it seems, other people and distros are already interested - for example Manjaro. > > It's also a chance to (maybe in the near future) integrate with a splash painted by EFI and/or GRUB, before userspace has even started. Maybe I've sounded too optimistic now. So fundamentally I don't think an in-kernel bootsplash is a bad idea. But most likely you want this on a highly embedded system, which probably is compiled for your exact hw, with pretty much everything built in. Also, no fbcon, maybe even no vt subsystem at all. Definitely not your general purpose distro. Your proposal to work on top of fbcon doesn't fix that niche. Now for your problem, which seems to be to have a working bootsplash for a general purpose distro, specifically for the bug where plymouth prevents the real drm driver from loading: Adding an in-kernel bootsplash doesn't make any sense, at least not to me. Instead I think the right action is to fix the problem, both in the kernel and in userspace. All the problems below have fairly simple solutions, but there's imo no point in talking technical solutions for specific problems when we're trying to fix the wrong problem. -Daniel >> But I'm really not sold on the current integration path being anywhere >> near close to a good idea long-term. > Sure, that's a valid concern. > > So there's two questions I understand from you here: > > 1. Do I really need to build on top of the console driver? > 2. If not (1), then can I build on top of KMS instead? > > > Let's look at this... > > 1. The starting point was that the kernel's built-in terminal emulator, fbcon, is the "fallback" thing to display when no graphical application is running. It is hidden automatically as soon as a program switches to KD_GRAPHICS, and reappears as soon as that program switches back to KD_TEXT, or dies. > It seemed desirable to me to want the same behavior for a splash screen. > > Furthermore, when fbcon runs, there is already a mode set. Whatever mode that may be, it's good enough for us. > It makes sense to re-use the same mode. > (This isn't really important for FB, but would be important when talking about drmcon). > > Since fbcon and the splash will never be shown at the same time, it makes sense to re-use whatever framebuffer fbcon is writing into, and silence fbcon during this time (that's what my dummyops do). > > When the splash is disabled, it needs to show the text that was hidden. So what I do is to call update_screen(vc_cons[fg_console].d) and also restore the original fbcon character rendering operations, thus allowing it to re-render the screen. > > > It thus seemed sensible to me to work inside of fbcon. > > > Let's stay at the FB level for the sake of taking things step by step. How would I solve this without hooking into fbcon? > > To shut up fbcon, I could play with do_console_blank() and do_console_unblank(). These are called when changing between KD_GRAPHICS and KD_TEXT. I'd then have to introduce additional logic for the KD_TEXT state, which switches between showing fbcon and showing the splash. I haven't tried this, but fair enough. > > To decide when to render, I'd have to have a hook that tells me when an FB mode changes, or the device disappears, or a new device appears. With fbcon, I can simply draw my splash in the fbcon_switch() function, not needing to care about whether this is a good time and whether I have a device underneath my feet. If fbcon can draw, then so can I. > > > 2. Let's assume we follow the ideas from the final paragraphs of (1) above, and also move to KMS. How would I deal with setting modes, etc.? I wouldn't want to change modes, and I also can't always get a new framebuffer for background buffering - think devices that only have a single framebuffer, such as a fictional efidrm, or devices with little VRAM. So if these semantics get figured out for a future drmcon, then it makes sense to just double-purpose its framebuffer. After all, the console framebuffer is the one shown as a fallback, when no other process is using the graphics mode. Otherwise, I'd have to check which one to show: The splash, or the text? > > > > So... it seemed helpful to me to build on top of the graphical console driver and double-purpose it, because it takes away the need to think about "what mode do I use", "which framebuffer to draw on", "when is it safe to draw", and so forth. > > If you disagree with that, or even think that it's easier to do outside fbcon, I'd be grateful to hear ideas on how to implement it. Maybe it wasn't the best decision - but as the old saying goes, "it seemed like a very good idea at the time". > > > As for the FB/KMS discussion: > Since I decided to build on top of the only graphical console driver that we have, I have no choice: fbcon builds on fbdev, and thus the bootsplash is on fbdev, too. Complaining that it's not on KMS is a red herring - after all, it does work on KMS drivers, and people are happy with fbcon on KMS as well. > > > If integration and future paths are to be discussed, let's first talk about whether to move the splash inside/outside the console driver (fbcon). -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Date: Wed, 20 Dec 2017 15:11:49 +0000 Subject: Re: [RFC PATCH v2 00/13] Kernel based bootsplash Message-Id: List-Id: References: <20171213194755.3409-1-mstaudt@suse.de> <20171219161630.GI26573@phenom.ffwll.local> <2f8a1a08-911d-a511-2968-4d89418ac212@suse.de> <573d4050-7607-b8e4-7552-83966f551ba3@suse.de> <20171220094355.GJ26573@phenom.ffwll.local> <20171220101421.GM26573@phenom.ffwll.local> <5dc7f218-9113-fad3-c0a8-883c4bae4e02@suse.de> In-Reply-To: <5dc7f218-9113-fad3-c0a8-883c4bae4e02@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Max Staudt Cc: Linux Fbdev development list , michal@markovi.net, Bartlomiej Zolnierkiewicz , sndirsch@suse.com, Oliver Neukum , Takashi Iwai , dri-devel , Linux Kernel Mailing List , Neil Armstrong , philm@manjaro.org, =?UTF-8?Q?Bero_Rosenkr=C3=A4nzer?= On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt wrote: > On 12/20/2017 11:14 AM, Daniel Vetter wrote: >> btw since I'm probably sounding a bit too grumpy here: I'd very much >> support this. I think bootsplash in kernel has a bunch of uses, and it >> shouldn't be hard to get non-suse people to cheer for it (makes merging >> easier if it's not just a one-off hack). > > Thank you! > > As it seems, other people and distros are already interested - for example Manjaro. > > It's also a chance to (maybe in the near future) integrate with a splash painted by EFI and/or GRUB, before userspace has even started. Maybe I've sounded too optimistic now. So fundamentally I don't think an in-kernel bootsplash is a bad idea. But most likely you want this on a highly embedded system, which probably is compiled for your exact hw, with pretty much everything built in. Also, no fbcon, maybe even no vt subsystem at all. Definitely not your general purpose distro. Your proposal to work on top of fbcon doesn't fix that niche. Now for your problem, which seems to be to have a working bootsplash for a general purpose distro, specifically for the bug where plymouth prevents the real drm driver from loading: Adding an in-kernel bootsplash doesn't make any sense, at least not to me. Instead I think the right action is to fix the problem, both in the kernel and in userspace. All the problems below have fairly simple solutions, but there's imo no point in talking technical solutions for specific problems when we're trying to fix the wrong problem. -Daniel >> But I'm really not sold on the current integration path being anywhere >> near close to a good idea long-term. > Sure, that's a valid concern. > > So there's two questions I understand from you here: > > 1. Do I really need to build on top of the console driver? > 2. If not (1), then can I build on top of KMS instead? > > > Let's look at this... > > 1. The starting point was that the kernel's built-in terminal emulator, fbcon, is the "fallback" thing to display when no graphical application is running. It is hidden automatically as soon as a program switches to KD_GRAPHICS, and reappears as soon as that program switches back to KD_TEXT, or dies. > It seemed desirable to me to want the same behavior for a splash screen. > > Furthermore, when fbcon runs, there is already a mode set. Whatever mode that may be, it's good enough for us. > It makes sense to re-use the same mode. > (This isn't really important for FB, but would be important when talking about drmcon). > > Since fbcon and the splash will never be shown at the same time, it makes sense to re-use whatever framebuffer fbcon is writing into, and silence fbcon during this time (that's what my dummyops do). > > When the splash is disabled, it needs to show the text that was hidden. So what I do is to call update_screen(vc_cons[fg_console].d) and also restore the original fbcon character rendering operations, thus allowing it to re-render the screen. > > > It thus seemed sensible to me to work inside of fbcon. > > > Let's stay at the FB level for the sake of taking things step by step. How would I solve this without hooking into fbcon? > > To shut up fbcon, I could play with do_console_blank() and do_console_unblank(). These are called when changing between KD_GRAPHICS and KD_TEXT. I'd then have to introduce additional logic for the KD_TEXT state, which switches between showing fbcon and showing the splash. I haven't tried this, but fair enough. > > To decide when to render, I'd have to have a hook that tells me when an FB mode changes, or the device disappears, or a new device appears. With fbcon, I can simply draw my splash in the fbcon_switch() function, not needing to care about whether this is a good time and whether I have a device underneath my feet. If fbcon can draw, then so can I. > > > 2. Let's assume we follow the ideas from the final paragraphs of (1) above, and also move to KMS. How would I deal with setting modes, etc.? I wouldn't want to change modes, and I also can't always get a new framebuffer for background buffering - think devices that only have a single framebuffer, such as a fictional efidrm, or devices with little VRAM. So if these semantics get figured out for a future drmcon, then it makes sense to just double-purpose its framebuffer. After all, the console framebuffer is the one shown as a fallback, when no other process is using the graphics mode. Otherwise, I'd have to check which one to show: The splash, or the text? > > > > So... it seemed helpful to me to build on top of the graphical console driver and double-purpose it, because it takes away the need to think about "what mode do I use", "which framebuffer to draw on", "when is it safe to draw", and so forth. > > If you disagree with that, or even think that it's easier to do outside fbcon, I'd be grateful to hear ideas on how to implement it. Maybe it wasn't the best decision - but as the old saying goes, "it seemed like a very good idea at the time". > > > As for the FB/KMS discussion: > Since I decided to build on top of the only graphical console driver that we have, I have no choice: fbcon builds on fbdev, and thus the bootsplash is on fbdev, too. Complaining that it's not on KMS is a red herring - after all, it does work on KMS drivers, and people are happy with fbcon on KMS as well. > > > If integration and future paths are to be discussed, let's first talk about whether to move the splash inside/outside the console driver (fbcon). -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [RFC PATCH v2 00/13] Kernel based bootsplash Date: Wed, 20 Dec 2017 16:11:49 +0100 Message-ID: References: <20171213194755.3409-1-mstaudt@suse.de> <20171219161630.GI26573@phenom.ffwll.local> <2f8a1a08-911d-a511-2968-4d89418ac212@suse.de> <573d4050-7607-b8e4-7552-83966f551ba3@suse.de> <20171220094355.GJ26573@phenom.ffwll.local> <20171220101421.GM26573@phenom.ffwll.local> <5dc7f218-9113-fad3-c0a8-883c4bae4e02@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) by gabe.freedesktop.org (Postfix) with ESMTPS id 015716E0D7 for ; Wed, 20 Dec 2017 15:11:50 +0000 (UTC) Received: by mail-io0-x236.google.com with SMTP id v186so17654036iod.7 for ; Wed, 20 Dec 2017 07:11:50 -0800 (PST) In-Reply-To: <5dc7f218-9113-fad3-c0a8-883c4bae4e02@suse.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Max Staudt Cc: Linux Fbdev development list , michal@markovi.net, Bartlomiej Zolnierkiewicz , sndirsch@suse.com, Oliver Neukum , Takashi Iwai , dri-devel , Linux Kernel Mailing List , Neil Armstrong , philm@manjaro.org, =?UTF-8?Q?Bero_Rosenkr=C3=A4nzer?= List-Id: dri-devel@lists.freedesktop.org T24gV2VkLCBEZWMgMjAsIDIwMTcgYXQgMzo1NSBQTSwgTWF4IFN0YXVkdCA8bXN0YXVkdEBzdXNl LmRlPiB3cm90ZToKPiBPbiAxMi8yMC8yMDE3IDExOjE0IEFNLCBEYW5pZWwgVmV0dGVyIHdyb3Rl Ogo+PiBidHcgc2luY2UgSSdtIHByb2JhYmx5IHNvdW5kaW5nIGEgYml0IHRvbyBncnVtcHkgaGVy ZTogSSdkIHZlcnkgbXVjaAo+PiBzdXBwb3J0IHRoaXMuIEkgdGhpbmsgYm9vdHNwbGFzaCBpbiBr ZXJuZWwgaGFzIGEgYnVuY2ggb2YgdXNlcywgYW5kIGl0Cj4+IHNob3VsZG4ndCBiZSBoYXJkIHRv IGdldCBub24tc3VzZSBwZW9wbGUgdG8gY2hlZXIgZm9yIGl0IChtYWtlcyBtZXJnaW5nCj4+IGVh c2llciBpZiBpdCdzIG5vdCBqdXN0IGEgb25lLW9mZiBoYWNrKS4KPgo+IFRoYW5rIHlvdSEKPgo+ IEFzIGl0IHNlZW1zLCBvdGhlciBwZW9wbGUgYW5kIGRpc3Ryb3MgYXJlIGFscmVhZHkgaW50ZXJl c3RlZCAtIGZvciBleGFtcGxlIE1hbmphcm8uCj4KPiBJdCdzIGFsc28gYSBjaGFuY2UgdG8gKG1h eWJlIGluIHRoZSBuZWFyIGZ1dHVyZSkgaW50ZWdyYXRlIHdpdGggYSBzcGxhc2ggcGFpbnRlZCBi eSBFRkkgYW5kL29yIEdSVUIsIGJlZm9yZSB1c2Vyc3BhY2UgaGFzIGV2ZW4gc3RhcnRlZC4KCk1h eWJlIEkndmUgc291bmRlZCB0b28gb3B0aW1pc3RpYyBub3cuCgpTbyBmdW5kYW1lbnRhbGx5IEkg ZG9uJ3QgdGhpbmsgYW4gaW4ta2VybmVsIGJvb3RzcGxhc2ggaXMgYSBiYWQgaWRlYS4KQnV0IG1v c3QgbGlrZWx5IHlvdSB3YW50IHRoaXMgb24gYSBoaWdobHkgZW1iZWRkZWQgc3lzdGVtLCB3aGlj aApwcm9iYWJseSBpcyBjb21waWxlZCBmb3IgeW91ciBleGFjdCBodywgd2l0aCBwcmV0dHkgbXVj aCBldmVyeXRoaW5nCmJ1aWx0IGluLiBBbHNvLCBubyBmYmNvbiwgbWF5YmUgZXZlbiBubyB2dCBz dWJzeXN0ZW0gYXQgYWxsLgpEZWZpbml0ZWx5IG5vdCB5b3VyIGdlbmVyYWwgcHVycG9zZSBkaXN0 cm8uCgpZb3VyIHByb3Bvc2FsIHRvIHdvcmsgb24gdG9wIG9mIGZiY29uIGRvZXNuJ3QgZml4IHRo YXQgbmljaGUuCgpOb3cgZm9yIHlvdXIgcHJvYmxlbSwgd2hpY2ggc2VlbXMgdG8gYmUgdG8gaGF2 ZSBhIHdvcmtpbmcgYm9vdHNwbGFzaApmb3IgYSBnZW5lcmFsIHB1cnBvc2UgZGlzdHJvLCBzcGVj aWZpY2FsbHkgZm9yIHRoZSBidWcgd2hlcmUgcGx5bW91dGgKcHJldmVudHMgdGhlIHJlYWwgZHJt IGRyaXZlciBmcm9tIGxvYWRpbmc6IEFkZGluZyBhbiBpbi1rZXJuZWwKYm9vdHNwbGFzaCBkb2Vz bid0IG1ha2UgYW55IHNlbnNlLCBhdCBsZWFzdCBub3QgdG8gbWUuIEluc3RlYWQgSSB0aGluawp0 aGUgcmlnaHQgYWN0aW9uIGlzIHRvIGZpeCB0aGUgcHJvYmxlbSwgYm90aCBpbiB0aGUga2VybmVs IGFuZCBpbgp1c2Vyc3BhY2UuCgpBbGwgdGhlIHByb2JsZW1zIGJlbG93IGhhdmUgZmFpcmx5IHNp bXBsZSBzb2x1dGlvbnMsIGJ1dCB0aGVyZSdzIGltbwpubyBwb2ludCBpbiB0YWxraW5nIHRlY2hu aWNhbCBzb2x1dGlvbnMgZm9yIHNwZWNpZmljIHByb2JsZW1zIHdoZW4Kd2UncmUgdHJ5aW5nIHRv IGZpeCB0aGUgd3JvbmcgcHJvYmxlbS4KLURhbmllbAoKPj4gQnV0IEknbSByZWFsbHkgbm90IHNv bGQgb24gdGhlIGN1cnJlbnQgaW50ZWdyYXRpb24gcGF0aCBiZWluZyBhbnl3aGVyZQo+PiBuZWFy IGNsb3NlIHRvIGEgZ29vZCBpZGVhIGxvbmctdGVybS4KPiBTdXJlLCB0aGF0J3MgYSB2YWxpZCBj b25jZXJuLgo+Cj4gU28gdGhlcmUncyB0d28gcXVlc3Rpb25zIEkgdW5kZXJzdGFuZCBmcm9tIHlv dSBoZXJlOgo+Cj4gMS4gRG8gSSByZWFsbHkgbmVlZCB0byBidWlsZCBvbiB0b3Agb2YgdGhlIGNv bnNvbGUgZHJpdmVyPwo+IDIuIElmIG5vdCAoMSksIHRoZW4gY2FuIEkgYnVpbGQgb24gdG9wIG9m IEtNUyBpbnN0ZWFkPwo+Cj4KPiBMZXQncyBsb29rIGF0IHRoaXMuLi4KPgo+IDEuIFRoZSBzdGFy dGluZyBwb2ludCB3YXMgdGhhdCB0aGUga2VybmVsJ3MgYnVpbHQtaW4gdGVybWluYWwgZW11bGF0 b3IsIGZiY29uLCBpcyB0aGUgImZhbGxiYWNrIiB0aGluZyB0byBkaXNwbGF5IHdoZW4gbm8gZ3Jh cGhpY2FsIGFwcGxpY2F0aW9uIGlzIHJ1bm5pbmcuIEl0IGlzIGhpZGRlbiBhdXRvbWF0aWNhbGx5 IGFzIHNvb24gYXMgYSBwcm9ncmFtIHN3aXRjaGVzIHRvIEtEX0dSQVBISUNTLCBhbmQgcmVhcHBl YXJzIGFzIHNvb24gYXMgdGhhdCBwcm9ncmFtIHN3aXRjaGVzIGJhY2sgdG8gS0RfVEVYVCwgb3Ig ZGllcy4KPiBJdCBzZWVtZWQgZGVzaXJhYmxlIHRvIG1lIHRvIHdhbnQgdGhlIHNhbWUgYmVoYXZp b3IgZm9yIGEgc3BsYXNoIHNjcmVlbi4KPgo+IEZ1cnRoZXJtb3JlLCB3aGVuIGZiY29uIHJ1bnMs IHRoZXJlIGlzIGFscmVhZHkgYSBtb2RlIHNldC4gV2hhdGV2ZXIgbW9kZSB0aGF0IG1heSBiZSwg aXQncyBnb29kIGVub3VnaCBmb3IgdXMuCj4gSXQgbWFrZXMgc2Vuc2UgdG8gcmUtdXNlIHRoZSBz YW1lIG1vZGUuCj4gKFRoaXMgaXNuJ3QgcmVhbGx5IGltcG9ydGFudCBmb3IgRkIsIGJ1dCB3b3Vs ZCBiZSBpbXBvcnRhbnQgd2hlbiB0YWxraW5nIGFib3V0IGRybWNvbikuCj4KPiBTaW5jZSBmYmNv biBhbmQgdGhlIHNwbGFzaCB3aWxsIG5ldmVyIGJlIHNob3duIGF0IHRoZSBzYW1lIHRpbWUsIGl0 IG1ha2VzIHNlbnNlIHRvIHJlLXVzZSB3aGF0ZXZlciBmcmFtZWJ1ZmZlciBmYmNvbiBpcyB3cml0 aW5nIGludG8sIGFuZCBzaWxlbmNlIGZiY29uIGR1cmluZyB0aGlzIHRpbWUgKHRoYXQncyB3aGF0 IG15IGR1bW15b3BzIGRvKS4KPgo+IFdoZW4gdGhlIHNwbGFzaCBpcyBkaXNhYmxlZCwgaXQgbmVl ZHMgdG8gc2hvdyB0aGUgdGV4dCB0aGF0IHdhcyBoaWRkZW4uIFNvIHdoYXQgSSBkbyBpcyB0byBj YWxsIHVwZGF0ZV9zY3JlZW4odmNfY29uc1tmZ19jb25zb2xlXS5kKSBhbmQgYWxzbyByZXN0b3Jl IHRoZSBvcmlnaW5hbCBmYmNvbiBjaGFyYWN0ZXIgcmVuZGVyaW5nIG9wZXJhdGlvbnMsIHRodXMg YWxsb3dpbmcgaXQgdG8gcmUtcmVuZGVyIHRoZSBzY3JlZW4uCj4KPgo+IEl0IHRodXMgc2VlbWVk IHNlbnNpYmxlIHRvIG1lIHRvIHdvcmsgaW5zaWRlIG9mIGZiY29uLgo+Cj4KPiBMZXQncyBzdGF5 IGF0IHRoZSBGQiBsZXZlbCBmb3IgdGhlIHNha2Ugb2YgdGFraW5nIHRoaW5ncyBzdGVwIGJ5IHN0 ZXAuIEhvdyB3b3VsZCBJIHNvbHZlIHRoaXMgd2l0aG91dCBob29raW5nIGludG8gZmJjb24/Cj4K PiBUbyBzaHV0IHVwIGZiY29uLCBJIGNvdWxkIHBsYXkgd2l0aCBkb19jb25zb2xlX2JsYW5rKCkg YW5kIGRvX2NvbnNvbGVfdW5ibGFuaygpLiBUaGVzZSBhcmUgY2FsbGVkIHdoZW4gY2hhbmdpbmcg YmV0d2VlbiBLRF9HUkFQSElDUyBhbmQgS0RfVEVYVC4gSSdkIHRoZW4gaGF2ZSB0byBpbnRyb2R1 Y2UgYWRkaXRpb25hbCBsb2dpYyBmb3IgdGhlIEtEX1RFWFQgc3RhdGUsIHdoaWNoIHN3aXRjaGVz IGJldHdlZW4gc2hvd2luZyBmYmNvbiBhbmQgc2hvd2luZyB0aGUgc3BsYXNoLiBJIGhhdmVuJ3Qg dHJpZWQgdGhpcywgYnV0IGZhaXIgZW5vdWdoLgo+Cj4gVG8gZGVjaWRlIHdoZW4gdG8gcmVuZGVy LCBJJ2QgaGF2ZSB0byBoYXZlIGEgaG9vayB0aGF0IHRlbGxzIG1lIHdoZW4gYW4gRkIgbW9kZSBj aGFuZ2VzLCBvciB0aGUgZGV2aWNlIGRpc2FwcGVhcnMsIG9yIGEgbmV3IGRldmljZSBhcHBlYXJz LiBXaXRoIGZiY29uLCBJIGNhbiBzaW1wbHkgZHJhdyBteSBzcGxhc2ggaW4gdGhlIGZiY29uX3N3 aXRjaCgpIGZ1bmN0aW9uLCBub3QgbmVlZGluZyB0byBjYXJlIGFib3V0IHdoZXRoZXIgdGhpcyBp cyBhIGdvb2QgdGltZSBhbmQgd2hldGhlciBJIGhhdmUgYSBkZXZpY2UgdW5kZXJuZWF0aCBteSBm ZWV0LiBJZiBmYmNvbiBjYW4gZHJhdywgdGhlbiBzbyBjYW4gSS4KPgo+Cj4gMi4gTGV0J3MgYXNz dW1lIHdlIGZvbGxvdyB0aGUgaWRlYXMgZnJvbSB0aGUgZmluYWwgcGFyYWdyYXBocyBvZiAoMSkg YWJvdmUsIGFuZCBhbHNvIG1vdmUgdG8gS01TLiBIb3cgd291bGQgSSBkZWFsIHdpdGggc2V0dGlu ZyBtb2RlcywgZXRjLj8gSSB3b3VsZG4ndCB3YW50IHRvIGNoYW5nZSBtb2RlcywgYW5kIEkgYWxz byBjYW4ndCBhbHdheXMgZ2V0IGEgbmV3IGZyYW1lYnVmZmVyIGZvciBiYWNrZ3JvdW5kIGJ1ZmZl cmluZyAtIHRoaW5rIGRldmljZXMgdGhhdCBvbmx5IGhhdmUgYSBzaW5nbGUgZnJhbWVidWZmZXIs IHN1Y2ggYXMgYSBmaWN0aW9uYWwgZWZpZHJtLCBvciBkZXZpY2VzIHdpdGggbGl0dGxlIFZSQU0u IFNvIGlmIHRoZXNlIHNlbWFudGljcyBnZXQgZmlndXJlZCBvdXQgZm9yIGEgZnV0dXJlIGRybWNv biwgdGhlbiBpdCBtYWtlcyBzZW5zZSB0byBqdXN0IGRvdWJsZS1wdXJwb3NlIGl0cyBmcmFtZWJ1 ZmZlci4gQWZ0ZXIgYWxsLCB0aGUgY29uc29sZSBmcmFtZWJ1ZmZlciBpcyB0aGUgb25lIHNob3du IGFzIGEgZmFsbGJhY2ssIHdoZW4gbm8gb3RoZXIgcHJvY2VzcyBpcyB1c2luZyB0aGUgZ3JhcGhp Y3MgbW9kZS4gT3RoZXJ3aXNlLCBJJ2QgaGF2ZSB0byBjaGVjayB3aGljaCBvbmUgdG8gc2hvdzog VGhlIHNwbGFzaCwgb3IgdGhlIHRleHQ/Cj4KPgo+Cj4gU28uLi4gaXQgc2VlbWVkIGhlbHBmdWwg dG8gbWUgdG8gYnVpbGQgb24gdG9wIG9mIHRoZSBncmFwaGljYWwgY29uc29sZSBkcml2ZXIgYW5k IGRvdWJsZS1wdXJwb3NlIGl0LCBiZWNhdXNlIGl0IHRha2VzIGF3YXkgdGhlIG5lZWQgdG8gdGhp bmsgYWJvdXQgIndoYXQgbW9kZSBkbyBJIHVzZSIsICJ3aGljaCBmcmFtZWJ1ZmZlciB0byBkcmF3 IG9uIiwgIndoZW4gaXMgaXQgc2FmZSB0byBkcmF3IiwgYW5kIHNvIGZvcnRoLgo+Cj4gSWYgeW91 IGRpc2FncmVlIHdpdGggdGhhdCwgb3IgZXZlbiB0aGluayB0aGF0IGl0J3MgZWFzaWVyIHRvIGRv IG91dHNpZGUgZmJjb24sIEknZCBiZSBncmF0ZWZ1bCB0byBoZWFyIGlkZWFzIG9uIGhvdyB0byBp bXBsZW1lbnQgaXQuIE1heWJlIGl0IHdhc24ndCB0aGUgYmVzdCBkZWNpc2lvbiAtIGJ1dCBhcyB0 aGUgb2xkIHNheWluZyBnb2VzLCAiaXQgc2VlbWVkIGxpa2UgYSB2ZXJ5IGdvb2QgaWRlYSBhdCB0 aGUgdGltZSIuCj4KPgo+IEFzIGZvciB0aGUgRkIvS01TIGRpc2N1c3Npb246Cj4gU2luY2UgSSBk ZWNpZGVkIHRvIGJ1aWxkIG9uIHRvcCBvZiB0aGUgb25seSBncmFwaGljYWwgY29uc29sZSBkcml2 ZXIgdGhhdCB3ZSBoYXZlLCBJIGhhdmUgbm8gY2hvaWNlOiBmYmNvbiBidWlsZHMgb24gZmJkZXYs IGFuZCB0aHVzIHRoZSBib290c3BsYXNoIGlzIG9uIGZiZGV2LCB0b28uIENvbXBsYWluaW5nIHRo YXQgaXQncyBub3Qgb24gS01TIGlzIGEgcmVkIGhlcnJpbmcgLSBhZnRlciBhbGwsIGl0IGRvZXMg d29yayBvbiBLTVMgZHJpdmVycywgYW5kIHBlb3BsZSBhcmUgaGFwcHkgd2l0aCBmYmNvbiBvbiBL TVMgYXMgd2VsbC4KPgo+Cj4gSWYgaW50ZWdyYXRpb24gYW5kIGZ1dHVyZSBwYXRocyBhcmUgdG8g YmUgZGlzY3Vzc2VkLCBsZXQncyBmaXJzdCB0YWxrIGFib3V0IHdoZXRoZXIgdG8gbW92ZSB0aGUg c3BsYXNoIGluc2lkZS9vdXRzaWRlIHRoZSBjb25zb2xlIGRyaXZlciAoZmJjb24pLgotLSAKRGFu aWVsIFZldHRlcgpTb2Z0d2FyZSBFbmdpbmVlciwgSW50ZWwgQ29ycG9yYXRpb24KKzQxICgwKSA3 OSAzNjUgNTcgNDggLSBodHRwOi8vYmxvZy5mZndsbC5jaApfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZl bEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFp bG1hbi9saXN0aW5mby9kcmktZGV2ZWwK