From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E3176C433F5 for ; Thu, 5 May 2022 00:57:54 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 41C648021F; Thu, 5 May 2022 02:57:51 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=quarantine dis=none) header.from=mediatek.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 5FD6E83D6B; Thu, 5 May 2022 02:57:48 +0200 (CEST) Received: from mailgw01.mediatek.com (unknown [60.244.123.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 1DBCF801CA for ; Thu, 5 May 2022 02:57:42 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=mediatek.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=weijie.gao@mediatek.com X-UUID: a4bb94872b0149b4b1fc62ff4f1658e3-20220505 X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.4, REQID:b0e232c0-fb76-434a-bb72-24324a6f48a4, OB:0, LO B:0,IP:0,URL:0,TC:0,Content:0,EDM:0,RT:0,SF:0,FILE:0,RULE:Release_Ham,ACTI ON:release,TS:0 X-CID-META: VersionHash:faefae9, CLOUDID:5b3d97b2-56b5-4c9e-8d83-0070b288eb6a, C OID:IGNORED,Recheck:0,SF:nil,TC:nil,Content:0,EDM:-3,File:nil,QS:0,BEC:nil X-UUID: a4bb94872b0149b4b1fc62ff4f1658e3-20220505 Received: from mtkexhb02.mediatek.inc [(172.21.101.103)] by mailgw01.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1011649156; Thu, 05 May 2022 08:57:37 +0800 Received: from MTKMBS07N2.mediatek.inc (172.21.101.141) by mtkmbs10n2.mediatek.inc (172.21.101.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Thu, 5 May 2022 08:57:36 +0800 Received: from mtkmbs11n2.mediatek.inc (172.21.101.187) by mtkmbs07n2.mediatek.inc (172.21.101.141) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 5 May 2022 08:57:36 +0800 Received: from mcddlt001.gcn.mediatek.inc (10.19.240.15) by mtkmbs11n2.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.792.3 via Frontend Transport; Thu, 5 May 2022 08:57:35 +0800 Message-ID: <8162bc80aa374ada1149292829128142eb1b9d3e.camel@mediatek.com> Subject: Re: [PATCH v3 00/15] Add support for MediaTek MT7621 SoC From: Weijie Gao To: Tom Rini , Marek =?ISO-8859-1?Q?Beh=FAn?= CC: Stefan Roese , , GSS_MTK_Uboot_upstream Date: Thu, 5 May 2022 08:57:35 +0800 In-Reply-To: <20220501125209.GF1182808@bill-the-cat> References: <20220428181955.1717ea7d@thinkpad> <3363c536747a3519b2a1eb8d22c029bfd02cc507.camel@mediatek.com> <055adba5a54f3d18ea310cdc7616f212bcc6c61e.camel@mediatek.com> <20220429171330.3f8e3d39@thinkpad> <20220430154804.3593a53e@thinkpad> <20220501125209.GF1182808@bill-the-cat> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1-2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MTK: N X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean On Sun, 2022-05-01 at 08:52 -0400, Tom Rini wrote: > On Sat, Apr 30, 2022 at 03:48:04PM +0200, Marek Behún wrote: > > On Sat, 30 Apr 2022 21:31:15 +0800 > > Weijie Gao wrote: > > > > > On Fri, 2022-04-29 at 17:13 +0200, Marek Behún wrote: > > > > On Fri, 29 Apr 2022 15:59:44 +0800 > > > > Weijie Gao wrote: > > > > > > > > > On Fri, 2022-04-29 at 08:15 +0200, Stefan Roese wrote: > > > > > > Hi Weijie > > > > > > > > > > > > On 4/29/22 03:23, Weijie Gao wrote: > > > > > > > Hi Marek, > > > > > > > > > > > > > > Yes. MT7621 does need such a proprietary binary for DDR > > > > > > > initialization > > > > > > > and calibration. That's why I submit only the ram- > > > > > > > bootable part > > > > > > > here. > > > > > > > > > > > > > > I'm considering to create a preloader to load and run DDR > > > > > > > init&calib > > > > > > > binary and ram-bootable u-boot image. The ram-bootable u- > > > > > > > boot > > > > > > > image > > > > > > > can be appended to the proloader to form the flash- > > > > > > > bootable > > > > > > > bootloader. > > > > > > > > > > > > > > The source code of preloader will be uploaded to > > > > > > > github. > > > > > > > > > > > > Just to be sure: You are not implementing this preloader as > > > > > > an U- > > > > > > Boot > > > > > > SPL loader, as this would conflict with U-Boot's GPL > > > > > > compatibility? > > > > > > > > > > Yes. Submitting the source code of this binary also violates > > > > > MTK's > > > > > non- > > > > > disclosure agreement. > > > > > > > > Isn't it possible to submit the DDR training code in binary > > > > version, > > > > and somehow call into it from SPL? > > > > > > It's possible and I've already implemented it. But will u-boot > > > accept > > > binary file? > > > > U-Boot at least accepts drivers that require proprietary firmware > > to > > load (bnxt driver, for example). > > > > I don't know whether a binary firmware can be accepted into the U- > > Boot > > repository, whether in a separate file or as an u8 array in a .c > > file, > > but it should at least be possible to make it so that the user can > > compile it thsemsevles to be bundled, i.e. create a Kconfig option > > that > > configures a path to the firmware. If it is present, it will be > > compiled with DDR training bundled. > > > > Stefan, Tom, can this be done? > > > > BTW, Weijie, can I already test this on mt7621 board, also with DDR > > training? Can you send me the patch that adds calling the > > proprietary > > code? > > At the high level, I would make a further disappointed sigh and note > the > NXP ddr firmware blobs, the binary blobs we pull in for x86, and all > of > the other blobs we bring in today via binman. Please make use of one > of > these otherwise existing mechanics to bring in the required DDR blobs > here. > At lease there are ways to achieve this. Thanks for the note.