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 68601C433F5 for ; Sun, 2 Jan 2022 00:28:56 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 9813081277; Sun, 2 Jan 2022 01:28:53 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="sqMsPQRr"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 2BC76804C8; Sun, 2 Jan 2022 01:28:51 +0100 (CET) Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) (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 7E81981277 for ; Sun, 2 Jan 2022 01:28:47 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=pali@kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7C5E260C51; Sun, 2 Jan 2022 00:28:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 91667C36AEA; Sun, 2 Jan 2022 00:28:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1641083324; bh=lAB8nSwjNyeK1GLZSzYXvOcnTnfiibwI2ncdoHFaad4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=sqMsPQRrYnsjnBEUWELLh2IfDmDO5gLv94qcxw507zyUA2dDn7/O9M7jAWrd10in4 0GSogrEGKum6OpZKy24C6DuOZQDqL14JyKKA6jjUBs8yRbwss1ERUEy7DOfYD81zeT ebQoqoRe3x9M7Me8grE4lbk+GaEQZ4sTJatTbEKkXLVG4l30/rFyfurdWlqqVby54V skWXXxssUNjbwlFygFDvfEqWAbBKqK7vyUYzitGnLc7xWC+rFbNu0MgHunmLfDAa9K +DgW+egcFQKMM4W6mhHTrTs1vKOqqW88fpXALNHdlC3prnyXtnk9M3hpx+OrTTgH9U ln0jU81m6cIKg== Received: by pali.im (Postfix) id D1B89881; Sun, 2 Jan 2022 01:28:41 +0100 (CET) Date: Sun, 2 Jan 2022 01:28:41 +0100 From: Pali =?utf-8?B?Um9ow6Fy?= To: Tony Dinh Cc: Marek =?utf-8?B?QmVow7pu?= , U-Boot Mailing List , Stefan Roese , Tom Rini Subject: Re: kwboot: Marvell Dove UART booting Message-ID: <20220102002841.gl4oienifm2nv4bs@pali> References: <20220101215321.ryncu7girojzoeya@pali> <20220101231227.ugl7cjrdjen2m6pj@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180716 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.38 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.2 at phobos.denx.de X-Virus-Status: Clean On Saturday 01 January 2022 16:00:27 Tony Dinh wrote: > Hi Pali > > On Sat, Jan 1, 2022 at 3:12 PM Pali Rohár wrote: > > > > On Saturday 01 January 2022 14:54:34 Tony Dinh wrote: > > > Hi Pali, > > > > > > On Sat, Jan 1, 2022 at 1:53 PM Pali Rohár wrote: > > > > > > > > On Sunday 26 December 2021 13:41:03 Tony Dinh wrote: > > > > > Follow up on the UART booting session before. > > > > > > > > > > Thanks for the advice about the Reset Strapping documentation. I've > > > > > extracted the attachment 88AP510_Reset_Strapping.xls from the HW Spec > > > > > for Dove at: > > > > > https://www.kernel.org/doc/html/latest/arm/marvell.html > > > > > > > > > > Listed below are the Boot Modes that are relevant to this subject > > > > > (there are other Boot Modes for SATA, NAND but we are not interested > > > > > in those): > > > > > > > > > > 0x00 Direct boot from SPI > > > > > 0x01 Boot from SPI with 3 address cycles > > > > > 0x02 Boot from SPI with 4 address cycles > > > > > 0x0E Boot from UART0 using Xmodem > > > > > 0x0F Boot from UART1 using Xmodem > > > > > 0x10 Open BootROM debug prompt on UART0 > > > > > 0x11 Open BootROM debug prompt on UART1 > > > > > > > > > > So it does look like the jumper on this HP T5335z is actually to put > > > > > the box into BootROM debug mode using 0x10. And from there, we can use > > > > > 0x0E to put the BootROM into UART0 booting mode. > > > > > > > > > > Oddly, I've also tried booting from SPI while at the BootROM debug > > > > > prompt, but have not been successful with either 0x00, 0x01, or 0x02. > > > > > I was hoping that it would make testing easier if I could run "Boot > > > > > from SPI" to boot into Linux without having to remove the jumper. > > > > > > > > And which hex mode is activated when jumper is not set to that Debug > > > > prompt UART mode? You should be able to check current mode by reading > > > > 0xD00D0214 address which should contain latched sample at reset value. > > > > E.g. in U-Boot by 'md 0xD00D0214 1' command. > > > > > > Without the jumper inserted, it was set to 0x00. > > > > > > HP>> md 0xD00D0214 1 > > > d00d0214: 00000000 .... > > > > Sample at reset register should not be zero. So it is located at > > different address. You could try to look into the functional > > specification... > > It must have been the liquor yesterday :) of course there are other > settings in this register... it cannot be zero. > > > > > Maybe internal registers are at space 0xf1000000? Then register is 0xf10d0214 > > I think 0xf1000000 is more like it. I've double checked, the Kirkwood > SatR is 0xF1010030. > > Functional Spec: > "The BootROM firmware is located on the device’s Read Only Memory > (ROM), and is executed according to the sample at reset configuration > bits[4:0] in the Sample at Reset 0 Register (Table 976 p. 959)" > > HP>> md f10D0214 1 > f10d0214: b40a24a1 .$.. > > So it looks like the boot mode is 00001? Seems yes. 30th bit in 0xb40a24a1 is unset, so first boot mode table from 88AP510_Reset_Strapping.xls applies. Bits [4:0] are 0b00001, so bootmode is 0x01 - Boot from SPI with 3 address cycles. Which should correspondent to 'x 0x01' command. If it does not work then BootROM is broken. Note that 'x' command is broken in A385 BootROM, so I would not be surprised if it does not work in other SoCs too... You can try to figure out at which address is mapped this sample at reset register when CPU is running that debug boot prompt. Sometimes this register is R/W, so bootrom can use it as a "cache" for its own purposes (it does not update hardware). And in case you figure out how to update it, you could try to invoke BootROM reset to just re-enter boot sequence... and maybe bootrom starts booting from SPI. Just idea. > Thanks, > Tony