From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751796AbeCWCXA (ORCPT ); Thu, 22 Mar 2018 22:23:00 -0400 Received: from szxga02-in.huawei.com ([45.249.212.188]:5958 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751666AbeCWCW6 (ORCPT ); Thu, 22 Mar 2018 22:22:58 -0400 From: "liwei (CM)" To: Arnd Bergmann CC: Rob Herring , Mark Rutland , "xuwei (O)" , Catalin Marinas , Will Deacon , Vinayak Holikatti , "James E.J. Bottomley" , "Martin K. Petersen" , Kevin Hilman , Gregory CLEMENT , Thomas Petazzoni , Masahiro Yamada , Riku Voipio , Thierry Reding , Krzysztof Kozlowski , Eric Anholt , DTML , "Linux Kernel Mailing List" , Linux ARM , linux-scsi , zangleigang , Gengjianfeng , Guodong Xu , Zhangfei Gao , "Fengbaopeng (kevin, Kirin Solution Dept)" Subject: =?utf-8?B?562U5aSNOiBbUEFUQ0ggdjggMi81XSBkdC1iaW5kaW5nczogc2NzaTogdWZz?= =?utf-8?Q?:_add_document_for_hisi-ufs?= Thread-Topic: [PATCH v8 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs Thread-Index: AQHTpLNt7xq76dhVgkeSgBp0Vy2vQaOrAJgAgDJE6ZA= Date: Fri, 23 Mar 2018 02:22:33 +0000 Message-ID: <1699CE87DE933F49876AD744B5DC140FA584ED@DGGEMM506-MBS.china.huawei.com> References: <20180213101412.5717-1-liwei213@huawei.com> <20180213101412.5717-3-liwei213@huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.189.155.72] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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 base64 to 8bit by mail.home.local id w2N2N5oi014959 Hi, Arnd Sorry to bother you again, please take the time to review the patch. Are there any other suggestions? Looking forward to your reply. -----邮件原件----- 发件人: arndbergmann@gmail.com [mailto:arndbergmann@gmail.com] 代表 Arnd Bergmann 发送时间: 2018年2月19日 17:58 收件人: liwei (CM) 抄送: Rob Herring; Mark Rutland; xuwei (O); Catalin Marinas; Will Deacon; Vinayak Holikatti; James E.J. Bottomley; Martin K. Petersen; Kevin Hilman; Gregory CLEMENT; Thomas Petazzoni; Masahiro Yamada; Riku Voipio; Thierry Reding; Krzysztof Kozlowski; Eric Anholt; DTML; Linux Kernel Mailing List; Linux ARM; linux-scsi; zangleigang; Gengjianfeng; Guodong Xu; Zhangfei Gao; Fengbaopeng (kevin, Kirin Solution Dept) 主题: Re: [PATCH v8 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs On Tue, Feb 13, 2018 at 11:14 AM, Li Wei wrote: > add ufs node document for Hisilicon. > > Signed-off-by: Li Wei > --- > Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 37 > ++++++++++++++++++++++ > 1 file changed, 37 insertions(+) > create mode 100644 Documentation/devicetree/bindings/ufs/ufs-hisi.txt I'm pretty sure we've discussed it before, but can you make this so that the generic properties are part of the ufshcd binding, and you refer to it from here, only describing in what ways the hisi ufs binding differs from the standard? > diff --git a/Documentation/devicetree/bindings/ufs/ufs-hisi.txt > b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt > new file mode 100644 > index 000000000000..0d21b57496cf > --- /dev/null > +++ b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt > @@ -0,0 +1,37 @@ > +* Hisilicon Universal Flash Storage (UFS) Host Controller > + > +UFS nodes are defined to describe on-chip UFS hardware macro. > +Each UFS Host Controller should have its own node. > + > +Required properties: > +- compatible : compatible list, contains one of the following - > + "hisilicon,hi3660-ufs", "jedec,ufs-1.1" for hisi ufs > + host controller present on Hi36xx chipset. > +- reg : should contain UFS register address space & UFS SYS CTRL register address, > +- interrupt-parent : interrupt device > +- interrupts : interrupt number > +- clocks : List of phandle and clock specifier pairs > +- clock-names : List of clock input name strings sorted in the same > + order as the clocks property. > +"ref_clk", "phy_clk" is optional The clock names sound generic enough, should we have both in the generic binding? Do you mean that add a "phy_clk" to ufshcd-pltfrm 's bindings? At present, it seems that in the implementation of generic code, apart from "ref_clk" may have special processing, other clk will not have special processing and simply parse and enable; Referring to ufs-qcom binding, I think "phy_clk" can be named "iface_clk", this "iface_clk" exists in ufshcd-pltfrm bindings;If so, "ref_clk", "iface_clk" are both in the generic binding,we will remove them here. Is that okay? > +- resets : reset node register, one reset the clk and the other reset the controller > +- reset-names : describe reset node register This looks incomplete. What is the name of the reset line supposed to be? I'd also suggest you document it in the ufshcd binding instead. The "rst" corresponds to reset the whole UFS IP, and " arst " only reset the APB/AXI bus. Discussed with our soc colleagues that "arst" is assert by default and needs to deassert . But I think it may be difficult to add this to common code, or it may not be necessary; Other manufacturers may not need to do this soc init because they probably already done in the bootloader phase. Even if they need to do it, it's probably different from us. We need to make sure that our ufs works even if not do soc init during the bootloader phase. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: "liwei (CM)" Subject: =?utf-8?B?562U5aSNOiBbUEFUQ0ggdjggMi81XSBkdC1iaW5kaW5nczogc2NzaTogdWZz?= =?utf-8?Q?:_add_document_for_hisi-ufs?= Date: Fri, 23 Mar 2018 02:22:33 +0000 Message-ID: <1699CE87DE933F49876AD744B5DC140FA584ED@DGGEMM506-MBS.china.huawei.com> References: <20180213101412.5717-1-liwei213@huawei.com> <20180213101412.5717-3-liwei213@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: Content-Language: zh-CN Sender: linux-kernel-owner@vger.kernel.org To: Arnd Bergmann Cc: Rob Herring , Mark Rutland , "xuwei (O)" , Catalin Marinas , Will Deacon , Vinayak Holikatti , "James E.J. Bottomley" , "Martin K. Petersen" , Kevin Hilman , Gregory CLEMENT , Thomas Petazzoni , Masahiro Yamada , Riku Voipio , Thierry Reding , Krzysztof Kozlowski , Eric Anholt , DTML , Linux Kernel Mailing List List-Id: devicetree@vger.kernel.org SGksIEFybmQNClNvcnJ5IHRvIGJvdGhlciB5b3UgYWdhaW4sIHBsZWFzZSB0YWtlIHRoZSB0aW1l IHRvIHJldmlldyB0aGUgcGF0Y2guIEFyZSB0aGVyZSBhbnkgb3RoZXIgc3VnZ2VzdGlvbnM/DQpM b29raW5nIGZvcndhcmQgdG8geW91ciByZXBseS4NCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K 5Y+R5Lu25Lq6OiBhcm5kYmVyZ21hbm5AZ21haWwuY29tIFttYWlsdG86YXJuZGJlcmdtYW5uQGdt YWlsLmNvbV0g5Luj6KGoIEFybmQgQmVyZ21hbm4NCuWPkemAgeaXtumXtDogMjAxOOW5tDLmnIgx OeaXpSAxNzo1OA0K5pS25Lu25Lq6OiBsaXdlaSAoQ00pDQrmioTpgIE6IFJvYiBIZXJyaW5nOyBN YXJrIFJ1dGxhbmQ7IHh1d2VpIChPKTsgQ2F0YWxpbiBNYXJpbmFzOyBXaWxsIERlYWNvbjsgVmlu YXlhayBIb2xpa2F0dGk7IEphbWVzIEUuSi4gQm90dG9tbGV5OyBNYXJ0aW4gSy4gUGV0ZXJzZW47 IEtldmluIEhpbG1hbjsgR3JlZ29yeSBDTEVNRU5UOyBUaG9tYXMgUGV0YXp6b25pOyBNYXNhaGly byBZYW1hZGE7IFJpa3UgVm9pcGlvOyBUaGllcnJ5IFJlZGluZzsgS3J6eXN6dG9mIEtvemxvd3Nr aTsgRXJpYyBBbmhvbHQ7IERUTUw7IExpbnV4IEtlcm5lbCBNYWlsaW5nIExpc3Q7IExpbnV4IEFS TTsgbGludXgtc2NzaTsgemFuZ2xlaWdhbmc7IEdlbmdqaWFuZmVuZzsgR3VvZG9uZyBYdTsgWmhh bmdmZWkgR2FvOyBGZW5nYmFvcGVuZyAoa2V2aW4sIEtpcmluIFNvbHV0aW9uIERlcHQpDQrkuLvp opg6IFJlOiBbUEFUQ0ggdjggMi81XSBkdC1iaW5kaW5nczogc2NzaTogdWZzOiBhZGQgZG9jdW1l bnQgZm9yIGhpc2ktdWZzDQoNCk9uIFR1ZSwgRmViIDEzLCAyMDE4IGF0IDExOjE0IEFNLCBMaSBX ZWkgPGxpd2VpMjEzQGh1YXdlaS5jb20+IHdyb3RlOg0KPiBhZGQgdWZzIG5vZGUgZG9jdW1lbnQg Zm9yIEhpc2lsaWNvbi4NCj4NCj4gU2lnbmVkLW9mZi1ieTogTGkgV2VpIDxsaXdlaTIxM0BodWF3 ZWkuY29tPg0KPiAtLS0NCj4gIERvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy91ZnMv dWZzLWhpc2kudHh0IHwgMzcgDQo+ICsrKysrKysrKysrKysrKysrKysrKysNCj4gIDEgZmlsZSBj aGFuZ2VkLCAzNyBpbnNlcnRpb25zKCspDQo+ICBjcmVhdGUgbW9kZSAxMDA2NDQgRG9jdW1lbnRh dGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL3Vmcy91ZnMtaGlzaS50eHQNCg0KDQpJJ20gcHJldHR5 IHN1cmUgd2UndmUgZGlzY3Vzc2VkIGl0IGJlZm9yZSwgYnV0IGNhbiB5b3UgbWFrZSB0aGlzIHNv IHRoYXQgdGhlIGdlbmVyaWMgcHJvcGVydGllcyBhcmUgcGFydCBvZiB0aGUgdWZzaGNkIGJpbmRp bmcsIGFuZCB5b3UgcmVmZXIgdG8gaXQgZnJvbSBoZXJlLCBvbmx5IGRlc2NyaWJpbmcgaW4gd2hh dCB3YXlzIHRoZSBoaXNpIHVmcyBiaW5kaW5nIGRpZmZlcnMgZnJvbSB0aGUgc3RhbmRhcmQ/DQoN Cj4gZGlmZiAtLWdpdCBhL0RvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy91ZnMvdWZz LWhpc2kudHh0IA0KPiBiL0RvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy91ZnMvdWZz LWhpc2kudHh0DQo+IG5ldyBmaWxlIG1vZGUgMTAwNjQ0DQo+IGluZGV4IDAwMDAwMDAwMDAwMC4u MGQyMWI1NzQ5NmNmDQo+IC0tLSAvZGV2L251bGwNCj4gKysrIGIvRG9jdW1lbnRhdGlvbi9kZXZp Y2V0cmVlL2JpbmRpbmdzL3Vmcy91ZnMtaGlzaS50eHQNCj4gQEAgLTAsMCArMSwzNyBAQA0KPiAr KiBIaXNpbGljb24gVW5pdmVyc2FsIEZsYXNoIFN0b3JhZ2UgKFVGUykgSG9zdCBDb250cm9sbGVy DQo+ICsNCj4gK1VGUyBub2RlcyBhcmUgZGVmaW5lZCB0byBkZXNjcmliZSBvbi1jaGlwIFVGUyBo YXJkd2FyZSBtYWNyby4NCj4gK0VhY2ggVUZTIEhvc3QgQ29udHJvbGxlciBzaG91bGQgaGF2ZSBp dHMgb3duIG5vZGUuDQo+ICsNCj4gK1JlcXVpcmVkIHByb3BlcnRpZXM6DQo+ICstIGNvbXBhdGli bGUgICAgICAgIDogY29tcGF0aWJsZSBsaXN0LCBjb250YWlucyBvbmUgb2YgdGhlIGZvbGxvd2lu ZyAtDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiaGlzaWxpY29u LGhpMzY2MC11ZnMiLCAiamVkZWMsdWZzLTEuMSIgZm9yIGhpc2kgdWZzDQo+ICsgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBob3N0IGNvbnRyb2xsZXIgcHJlc2VudCBvbiBI aTM2eHggY2hpcHNldC4NCj4gKy0gcmVnICAgICAgICAgICAgICAgOiBzaG91bGQgY29udGFpbiBV RlMgcmVnaXN0ZXIgYWRkcmVzcyBzcGFjZSAmIFVGUyBTWVMgQ1RSTCByZWdpc3RlciBhZGRyZXNz LA0KPiArLSBpbnRlcnJ1cHQtcGFyZW50ICA6IGludGVycnVwdCBkZXZpY2UNCj4gKy0gaW50ZXJy dXB0cyAgICAgICAgOiBpbnRlcnJ1cHQgbnVtYmVyDQo+ICstIGNsb2NrcyAgICAgICAgICAgICAg IDogTGlzdCBvZiBwaGFuZGxlIGFuZCBjbG9jayBzcGVjaWZpZXIgcGFpcnMNCj4gKy0gY2xvY2st bmFtZXMgICAgICAgOiBMaXN0IG9mIGNsb2NrIGlucHV0IG5hbWUgc3RyaW5ncyBzb3J0ZWQgaW4g dGhlIHNhbWUNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9yZGVy IGFzIHRoZSBjbG9ja3MgcHJvcGVydHkuIA0KPiArInJlZl9jbGsiLCAicGh5X2NsayIgaXMgb3B0 aW9uYWwNCg0KVGhlIGNsb2NrIG5hbWVzIHNvdW5kIGdlbmVyaWMgZW5vdWdoLCBzaG91bGQgd2Ug aGF2ZSBib3RoIGluIHRoZSBnZW5lcmljIGJpbmRpbmc/DQoNCkRvIHlvdSBtZWFuIHRoYXQgYWRk IGEgInBoeV9jbGsiIHRvIHVmc2hjZC1wbHRmcm0gJ3MgYmluZGluZ3M/IA0KQXQgcHJlc2VudCwg aXQgc2VlbXMgdGhhdCBpbiB0aGUgaW1wbGVtZW50YXRpb24gb2YgZ2VuZXJpYyBjb2RlLCBhcGFy dCBmcm9tICJyZWZfY2xrIiBtYXkgaGF2ZSBzcGVjaWFsIHByb2Nlc3NpbmcsIG90aGVyIGNsayB3 aWxsIG5vdCBoYXZlIHNwZWNpYWwgcHJvY2Vzc2luZyBhbmQgc2ltcGx5IHBhcnNlIGFuZCBlbmFi bGU7DQpSZWZlcnJpbmcgdG8gdWZzLXFjb20gYmluZGluZywgSSB0aGluayAicGh5X2NsayIgY2Fu IGJlIG5hbWVkICJpZmFjZV9jbGsiLCB0aGlzICJpZmFjZV9jbGsiIGV4aXN0cyBpbiB1ZnNoY2Qt cGx0ZnJtIGJpbmRpbmdzO0lmIHNvLCAicmVmX2NsayIsICJpZmFjZV9jbGsiIGFyZSBib3RoIGlu IHRoZSBnZW5lcmljIGJpbmRpbmcsd2Ugd2lsbCByZW1vdmUgdGhlbSBoZXJlLiBJcyB0aGF0IG9r YXk/DQoNCj4gKy0gcmVzZXRzICAgICAgICAgICAgOiByZXNldCBub2RlIHJlZ2lzdGVyLCBvbmUg cmVzZXQgdGhlIGNsayBhbmQgdGhlIG90aGVyIHJlc2V0IHRoZSBjb250cm9sbGVyDQo+ICstIHJl c2V0LW5hbWVzICAgICAgIDogZGVzY3JpYmUgcmVzZXQgbm9kZSByZWdpc3Rlcg0KDQpUaGlzIGxv b2tzIGluY29tcGxldGUuIFdoYXQgaXMgdGhlIG5hbWUgb2YgdGhlIHJlc2V0IGxpbmUgc3VwcG9z ZWQgdG8gYmU/DQpJJ2QgYWxzbyBzdWdnZXN0IHlvdSBkb2N1bWVudCBpdCBpbiB0aGUgdWZzaGNk IGJpbmRpbmcgaW5zdGVhZC4NCg0KVGhlICJyc3QiIGNvcnJlc3BvbmRzIHRvIHJlc2V0IHRoZSB3 aG9sZSBVRlMgSVAsIGFuZCAiIGFyc3QgIiBvbmx5IHJlc2V0IHRoZSBBUEIvQVhJIGJ1cy4gRGlz Y3Vzc2VkIHdpdGggb3VyIHNvYyBjb2xsZWFndWVzIHRoYXQgImFyc3QiIGlzIGFzc2VydCBieSBk ZWZhdWx0IGFuZCBuZWVkcyB0byBkZWFzc2VydCAuDQpCdXQgSSB0aGluayBpdCBtYXkgYmUgZGlm ZmljdWx0IHRvIGFkZCB0aGlzIHRvIGNvbW1vbiBjb2RlLCBvciBpdCBtYXkgbm90IGJlIG5lY2Vz c2FyeTsgDQpPdGhlciBtYW51ZmFjdHVyZXJzIG1heSBub3QgbmVlZCB0byBkbyB0aGlzIHNvYyBp bml0IGJlY2F1c2UgdGhleSBwcm9iYWJseSBhbHJlYWR5IGRvbmUgaW4gdGhlIGJvb3Rsb2FkZXIg cGhhc2UuIEV2ZW4gaWYgdGhleSBuZWVkIHRvIGRvIGl0LCBpdCdzIHByb2JhYmx5IGRpZmZlcmVu dCBmcm9tIHVzLg0KV2UgbmVlZCB0byBtYWtlIHN1cmUgdGhhdCBvdXIgdWZzIHdvcmtzIGV2ZW4g aWYgbm90IGRvIHNvYyBpbml0IGR1cmluZyB0aGUgYm9vdGxvYWRlciBwaGFzZS4NCg0KDQoNCg0K ICAgICAgQXJuZA0K From mboxrd@z Thu Jan 1 00:00:00 1970 From: liwei213@huawei.com (liwei (CM)) Date: Fri, 23 Mar 2018 02:22:33 +0000 Subject: =?utf-8?B?562U5aSNOiBbUEFUQ0ggdjggMi81XSBkdC1iaW5kaW5nczogc2NzaTogdWZz?= =?utf-8?Q?:_add_document_for_hisi-ufs?= In-Reply-To: References: <20180213101412.5717-1-liwei213@huawei.com> <20180213101412.5717-3-liwei213@huawei.com> Message-ID: <1699CE87DE933F49876AD744B5DC140FA584ED@DGGEMM506-MBS.china.huawei.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi, Arnd Sorry to bother you again, please take the time to review the patch. Are there any other suggestions? Looking forward to your reply. -----????----- ???: arndbergmann at gmail.com [mailto:arndbergmann at gmail.com] ?? Arnd Bergmann ????: 2018?2?19? 17:58 ???: liwei (CM) ??: Rob Herring; Mark Rutland; xuwei (O); Catalin Marinas; Will Deacon; Vinayak Holikatti; James E.J. Bottomley; Martin K. Petersen; Kevin Hilman; Gregory CLEMENT; Thomas Petazzoni; Masahiro Yamada; Riku Voipio; Thierry Reding; Krzysztof Kozlowski; Eric Anholt; DTML; Linux Kernel Mailing List; Linux ARM; linux-scsi; zangleigang; Gengjianfeng; Guodong Xu; Zhangfei Gao; Fengbaopeng (kevin, Kirin Solution Dept) ??: Re: [PATCH v8 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs On Tue, Feb 13, 2018 at 11:14 AM, Li Wei wrote: > add ufs node document for Hisilicon. > > Signed-off-by: Li Wei > --- > Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 37 > ++++++++++++++++++++++ > 1 file changed, 37 insertions(+) > create mode 100644 Documentation/devicetree/bindings/ufs/ufs-hisi.txt I'm pretty sure we've discussed it before, but can you make this so that the generic properties are part of the ufshcd binding, and you refer to it from here, only describing in what ways the hisi ufs binding differs from the standard? > diff --git a/Documentation/devicetree/bindings/ufs/ufs-hisi.txt > b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt > new file mode 100644 > index 000000000000..0d21b57496cf > --- /dev/null > +++ b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt > @@ -0,0 +1,37 @@ > +* Hisilicon Universal Flash Storage (UFS) Host Controller > + > +UFS nodes are defined to describe on-chip UFS hardware macro. > +Each UFS Host Controller should have its own node. > + > +Required properties: > +- compatible : compatible list, contains one of the following - > + "hisilicon,hi3660-ufs", "jedec,ufs-1.1" for hisi ufs > + host controller present on Hi36xx chipset. > +- reg : should contain UFS register address space & UFS SYS CTRL register address, > +- interrupt-parent : interrupt device > +- interrupts : interrupt number > +- clocks : List of phandle and clock specifier pairs > +- clock-names : List of clock input name strings sorted in the same > + order as the clocks property. > +"ref_clk", "phy_clk" is optional The clock names sound generic enough, should we have both in the generic binding? Do you mean that add a "phy_clk" to ufshcd-pltfrm 's bindings? At present, it seems that in the implementation of generic code, apart from "ref_clk" may have special processing, other clk will not have special processing and simply parse and enable; Referring to ufs-qcom binding, I think "phy_clk" can be named "iface_clk", this "iface_clk" exists in ufshcd-pltfrm bindings;If so, "ref_clk", "iface_clk" are both in the generic binding,we will remove them here. Is that okay? > +- resets : reset node register, one reset the clk and the other reset the controller > +- reset-names : describe reset node register This looks incomplete. What is the name of the reset line supposed to be? I'd also suggest you document it in the ufshcd binding instead. The "rst" corresponds to reset the whole UFS IP, and " arst " only reset the APB/AXI bus. Discussed with our soc colleagues that "arst" is assert by default and needs to deassert . But I think it may be difficult to add this to common code, or it may not be necessary; Other manufacturers may not need to do this soc init because they probably already done in the bootloader phase. Even if they need to do it, it's probably different from us. We need to make sure that our ufs works even if not do soc init during the bootloader phase. Arnd