From patchwork Wed Oct 19 06:47:57 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dhruva Gole X-Patchwork-Id: 1691805 X-Patchwork-Delegate: trini@ti.com Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de; envelope-from=u-boot-bounces@lists.denx.de; receiver=) Authentication-Results: legolas.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=ti.com header.i=@ti.com header.a=rsa-sha256 header.s=ti-com-17Q1 header.b=mWi/gp+j; dkim-atps=neutral Received: from phobos.denx.de (phobos.denx.de [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4MshC21jcvz23jk for ; Wed, 19 Oct 2022 17:48:30 +1100 (AEDT) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 30C1584F99; Wed, 19 Oct 2022 08:48:18 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=ti.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=ti.com header.i=@ti.com header.b="mWi/gp+j"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id B2A9584F92; Wed, 19 Oct 2022 08:48:16 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: from fllv0016.ext.ti.com (fllv0016.ext.ti.com [198.47.19.142]) (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 265A884F98 for ; Wed, 19 Oct 2022 08:48:13 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=ti.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=d-gole@ti.com Received: from lelv0266.itg.ti.com ([10.180.67.225]) by fllv0016.ext.ti.com (8.15.2/8.15.2) with ESMTP id 29J6m6Fc092607; Wed, 19 Oct 2022 01:48:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1666162086; bh=E5FGuKTUPhwm2KzL6QxbAMTtdEER6eCKg3bFsTfcybc=; h=From:To:CC:Subject:Date; b=mWi/gp+jJWzw7EC2sB05wkFo1f3q28Oxqkg1jK3YcpBZqrSqzZ9S4KJ7Y/vsXG05x xImHDZIDQvhFluqY4XgfdB5qtw5Xkuobg7AqBHOsm5P0mzxH5P2P6CvBhOKot9b2m/ xbf3nCXpgT5nyTtHakQND6NqnlJgNBL2SfAOZl8o= Received: from DFLE100.ent.ti.com (dfle100.ent.ti.com [10.64.6.21]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 29J6m64p068189 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 19 Oct 2022 01:48:06 -0500 Received: from DFLE104.ent.ti.com (10.64.6.25) by DFLE100.ent.ti.com (10.64.6.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.6; Wed, 19 Oct 2022 01:48:06 -0500 Received: from fllv0040.itg.ti.com (10.64.41.20) by DFLE104.ent.ti.com (10.64.6.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.6 via Frontend Transport; Wed, 19 Oct 2022 01:48:06 -0500 Received: from localhost (ileaxei01-snat2.itg.ti.com [10.180.69.6]) by fllv0040.itg.ti.com (8.15.2/8.15.2) with ESMTP id 29J6m4K1004549; Wed, 19 Oct 2022 01:48:05 -0500 From: Dhruva Gole To: Tom Rini CC: Vaishnav Achath , Nishanth Menon , "Julien Panis" , Dhruva Gole , Dave Gerlach , Vignesh Raghavendra , Georgi Vlaev , Subject: [PATCH 0/2] Enable OSPI Flash in AM62x SK EVM Date: Wed, 19 Oct 2022 12:17:57 +0530 Message-ID: <20221019064759.493607-1-d-gole@ti.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 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.6 at phobos.denx.de X-Virus-Status: Clean The AM62x SK EVM uses an OSPI Flash chip by cypress. We use OSPI DTR mode read / writes to this chip which helps us support high speed ops. The driver support is already present in upstream u-boot and this series just aims to enable that support for AM62x SK EVM. 1. Now the board can completely boot up from R5 SPL to U-Boot prompt from the OSPI Flash. 2. OSPI Flash can now be used from the U-Boot stage as well. A small catch though: Since we do DTR Read from OSPI Flash, one can't do an odd number of bytes read / write in DTR mode. However when we load the Image from Flash to the DDR/ RAM inorder to load the A53 SPL Stage, the generated DTB inside the FIT image is of an odd number of bytes. There is a strict check that prevents the read of odd number of bytes from the Flash. This causes the entire boot flow to freeze and hence I had to temporarily introduce a HACK in spl_spi.c. This hack essentially does the following: return count; else wherein we make sure to pass an extra count if count is odd. This seems to atleast let me boot up the board, however this solution is far from ideal and hence I haven't included it in this patch. How to solve this odd byte issue is something that I need some inputs with, currently I have 2 ideas: 1. Force all the Images contained within the FIT to have an even number of bytes. This can be done using padding of bytes toward the end maybe. 2. Modify the driver OR the caller to ensure that even number of bytes are read from OSPI Flash and then disregard the additional byte. I am not entirely sure yet if the upstream linux kernel handles this odd byte exceptions cleanly however I do know that unlike in u-boot where we have strict checks in place in spi_mem_dtr_supports_op() to ensure that data bytes are even, the checks in kernel are more lenient. Perhaps I will need to deep dive into the MTD Stack in kernel to see how it is being done there, if atall it even is. I would appreciate any inputs that the U-Boot community has in this matter. But for now this patch series in itself has all the necessary configs and DT changes needed to boot from OSPI Flash. Dhruva Gole (2): arm: dts: Enable OSPI for AM62-SK configs: enable OSPI related configs in AM62x arch/arm/dts/k3-am625-r5-sk.dts | 5 ++ arch/arm/dts/k3-am625-sk-u-boot.dtsi | 24 +++++++++ arch/arm/dts/k3-am625-sk.dts | 77 ++++++++++++++++++++++++++++ configs/am62x_evm_a53_defconfig | 19 +++++++ configs/am62x_evm_r5_defconfig | 22 ++++++++ 5 files changed, 147 insertions(+) diff --git a/common/spl/spl_spi.c b/common/spl/spl_spi.c index da6742416ed9..d147ac36f4ad 100644 --- a/common/spl/spl_spi.c +++ b/common/spl/spl_spi.c @@ -59,7 +59,11 @@ static ulong spl_spi_fit_read(struct spl_load_info *load, ulong sector, struct spi_flash *flash = load->dev; ulong ret; - ret = spi_flash_read(flash, sector, count, buf); + if (count%2 != 0) + ret = spi_flash_read(flash, sector, count+1, buf); + else + ret = spi_flash_read(flash, sector, count, buf); + printf("mylogs: %s#%d return = 0x%x\n", __func__, __LINE__, ret); if (!ret)