From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?ISO-8859-1?Q?J=F6rg?= Krause <joerg.krause@embedded.rocks>
Date: Thu, 26 Mar 2015 15:57:14 +0100
Subject: [U-Boot] [PATCH 1/1] ARM: mxs: get boot mode from OTP
In-Reply-To: <5513FC3A.8050606@denx.de>
References: <1427362746-8403-1-git-send-email-joerg.krause@embedded.rocks>
 <5513FC3A.8050606@denx.de>
Message-ID: <1427381834.21230.10.camel@embedded.rocks>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Stefano,

On Do, 2015-03-26 at 13:31 +0100, Stefano Babic wrote:
> Hi J?rg,
> 
> On 26/03/2015 10:39, J?rg Krause wrote:
> > Reading the GPIOs for getting the boot mode does not show the correct result
> > for USB boot mode in case the recovery switch, eg. BM2 for switching from NAND
> > to USB boot mode, is hold down while plugging in USB and released before U-Boot
> > is loaded by mxsldr.
> > 
> > This state is stored in the HW_OCOTP_ROM0 register. HW_OCOTP_ROM0[27:24] maps to
> > BM3-BM0, HW_OCOTP_ROM0[28] maps to voltage selector.
> > 
> > For using mxs_wait_mask_clr() add imx-common/misc.o to the SPL build.
> > 
> 
> As far as I understand from the manual, bootmode is *always* copied
> fromt the OTP after a reset. Then, I agree that is better to use OCOTP
> as the GPIOs. GPIOs were already sampled by ROM at reset and their value
> could be different when evaluated by SPL.

I fear the patch does not work as I expected. With OCOTP_ROM0 the boot
mode can be blown, but it does not present the state of the BM pads as I
understood from the RM. I thought the patch works because the boot mode
is read as USB (0x0) if I do USB recovery, but it's also 0x0 for NAND
boot.

Sadly, no reliable way to detect boot mode. Sorry for submitting to
early!

Best regards
J?rg Krause