[U-Boot] AM335x SPI boot not working

[U-Boot] AM335x SPI boot not working

[Lars Poeschel]

Hi!

I played a bit with spi boot on my am3359. It is currently not working with u-
boot at least with the machine I work here. Has anyone else problems with spi 
boot on am335x ?

On boot SPL reads a value from a processor register to determine from which 
device it was booting and it uses that value to continue booting process from 
that same device.
I found, that in my case the processor register contained a 0x0b and SPL could 
not match that to a hardware device. BOOT_DEVICE_SPI is defined as 0x15 in 
arch/arm/include/asm/arch-am33xx/spl.h. SPL does not find a mathch for 0x0b, 
decides this is an unknown value and stalls. So far so good.

I looked up in the technical reference manual if the value 0x15 is correct. I 
had TRM rev. F on my harddrive and found the value in 26.1.10.2, on page 4295 
and it is indeed 0x15 as in u-boot.
I looked on TI website for a new version of the TRM and they currently have 
rev. L. There I found in 26.1.10.2 on page 4960 that SPI boot has 0x0b!

My question is now how to best cope with this issue and if anybody has more 
information on what happend.
I don't know if they only made a mistake in the TRM and fixed that or if they 
have new silicone revisions that really have another boot device value for spi 
boot.
What can we do ?

Regards,
Lars

[U-Boot] AM335x SPI boot not working

[Tom Rini]

On Wed, Dec 16, 2015 at 03:34:24PM +0100, Lars Poeschel wrote:

> Hi!
> 
> I played a bit with spi boot on my am3359. It is currently not working with u-
> boot at least with the machine I work here. Has anyone else problems with spi 
> boot on am335x ?
> 
> On boot SPL reads a value from a processor register to determine from which 
> device it was booting and it uses that value to continue booting process from 
> that same device.
> I found, that in my case the processor register contained a 0x0b and SPL could 
> not match that to a hardware device. BOOT_DEVICE_SPI is defined as 0x15 in 
> arch/arm/include/asm/arch-am33xx/spl.h. SPL does not find a mathch for 0x0b, 
> decides this is an unknown value and stalls. So far so good.
> 
> I looked up in the technical reference manual if the value 0x15 is correct. I 
> had TRM rev. F on my harddrive and found the value in 26.1.10.2, on page 4295 
> and it is indeed 0x15 as in u-boot.
> I looked on TI website for a new version of the TRM and they currently have 
> rev. L. There I found in 26.1.10.2 on page 4960 that SPI boot has 0x0b!
> 
> My question is now how to best cope with this issue and if anybody has more 
> information on what happend.
> I don't know if they only made a mistake in the TRM and fixed that or if they 
> have new silicone revisions that really have another boot device value for spi 
> boot.
> What can we do ?

Sorry for the late reply.  It sounds like at some point post PG2.1 TI
changed at least the value used for SPI boot.  I have in the past
validated SPI boot on my AM335x GP EVM with PG2.1 silicon.  SPI boot on
this hardware is not supported officially due to I believe hardware
design issues.  Did you make any further progress here?  Did making the
value U-Boot checks by 0x0b make things suddenly work?  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160114/cd5a753b/attachment.sig>

[U-Boot] AM335x SPI boot not working

[Lars Poeschel]

Am Donnerstag, 14. Januar 2016, 16:01:00 schrieben Sie:
> On Wed, Dec 16, 2015 at 03:34:24PM +0100, Lars Poeschel wrote:
> > Hi!
> > 
> > I played a bit with spi boot on my am3359. It is currently not working
> > with u- boot at least with the machine I work here. Has anyone else
> > problems with spi boot on am335x ?
> > 
> > On boot SPL reads a value from a processor register to determine from
> > which
> > device it was booting and it uses that value to continue booting process
> > from that same device.
> > I found, that in my case the processor register contained a 0x0b and SPL
> > could not match that to a hardware device. BOOT_DEVICE_SPI is defined as
> > 0x15 in arch/arm/include/asm/arch-am33xx/spl.h. SPL does not find a
> > mathch for 0x0b, decides this is an unknown value and stalls. So far so
> > good.
> > 
> > I looked up in the technical reference manual if the value 0x15 is
> > correct. I had TRM rev. F on my harddrive and found the value in
> > 26.1.10.2, on page 4295 and it is indeed 0x15 as in u-boot.
> > I looked on TI website for a new version of the TRM and they currently
> > have
> > rev. L. There I found in 26.1.10.2 on page 4960 that SPI boot has 0x0b!
> > 
> > My question is now how to best cope with this issue and if anybody has
> > more
> > information on what happend.
> > I don't know if they only made a mistake in the TRM and fixed that or if
> > they have new silicone revisions that really have another boot device
> > value for spi boot.
> > What can we do ?
> 
> Sorry for the late reply.  It sounds like at some point post PG2.1 TI
> changed at least the value used for SPI boot.  I have in the past
> validated SPI boot on my AM335x GP EVM with PG2.1 silicon.  SPI boot on
> this hardware is not supported officially due to I believe hardware
> design issues.  Did you make any further progress here?  Did making the
> value U-Boot checks by 0x0b make things suddenly work?  Thanks!

I am not sure what you mean by "PG 2.1". Is that TI silicone revision ? 
According to the Sitara AM335x silicon errata the lasted revision they have 
out now is revision 2.1 which is the one I have tested on. So they must have 
changed the SPI boot value BEFORE revision 2.1.
Yeah, the thing I did was just to change the SPI boot value in the u-boot 
source and then SPI boot worked fine frome that on.
I would propose to let u-boot simply accept both values. They do not interfere 
with some other boot value. That should work for all revisions. What do you 
think ?

Regards,
Lars

[U-Boot] AM335x SPI boot not working

[Tom Rini]

On Mon, Jan 18, 2016 at 10:02:32AM +0100, Lars Poeschel wrote:
> Am Donnerstag, 14. Januar 2016, 16:01:00 schrieben Sie:
> > On Wed, Dec 16, 2015 at 03:34:24PM +0100, Lars Poeschel wrote:
> > > Hi!
> > > 
> > > I played a bit with spi boot on my am3359. It is currently not working
> > > with u- boot at least with the machine I work here. Has anyone else
> > > problems with spi boot on am335x ?
> > > 
> > > On boot SPL reads a value from a processor register to determine from
> > > which
> > > device it was booting and it uses that value to continue booting process
> > > from that same device.
> > > I found, that in my case the processor register contained a 0x0b and SPL
> > > could not match that to a hardware device. BOOT_DEVICE_SPI is defined as
> > > 0x15 in arch/arm/include/asm/arch-am33xx/spl.h. SPL does not find a
> > > mathch for 0x0b, decides this is an unknown value and stalls. So far so
> > > good.
> > > 
> > > I looked up in the technical reference manual if the value 0x15 is
> > > correct. I had TRM rev. F on my harddrive and found the value in
> > > 26.1.10.2, on page 4295 and it is indeed 0x15 as in u-boot.
> > > I looked on TI website for a new version of the TRM and they currently
> > > have
> > > rev. L. There I found in 26.1.10.2 on page 4960 that SPI boot has 0x0b!
> > > 
> > > My question is now how to best cope with this issue and if anybody has
> > > more
> > > information on what happend.
> > > I don't know if they only made a mistake in the TRM and fixed that or if
> > > they have new silicone revisions that really have another boot device
> > > value for spi boot.
> > > What can we do ?
> > 
> > Sorry for the late reply.  It sounds like at some point post PG2.1 TI
> > changed at least the value used for SPI boot.  I have in the past
> > validated SPI boot on my AM335x GP EVM with PG2.1 silicon.  SPI boot on
> > this hardware is not supported officially due to I believe hardware
> > design issues.  Did you make any further progress here?  Did making the
> > value U-Boot checks by 0x0b make things suddenly work?  Thanks!
> 
> I am not sure what you mean by "PG 2.1". Is that TI silicone revision ? 

Yes.

> According to the Sitara AM335x silicon errata the lasted revision they have 
> out now is revision 2.1 which is the one I have tested on. So they must have 
> changed the SPI boot value BEFORE revision 2.1.
> Yeah, the thing I did was just to change the SPI boot value in the u-boot 
> source and then SPI boot worked fine frome that on.
> I would propose to let u-boot simply accept both values. They do not interfere 
> with some other boot value. That should work for all revisions. What do you 
> think ?

I think we should just re-work things to accept either value.  I would
have sworn that I tested SPI booting on my AM335x GP EVM with the
current silicon version (2.1) but it's also enough of a pain that I
don't think it's worth re-validating things.  There's already a few
fixups in
arch/arm/cpu/armv7/omap-common/boot-common.c::save_omap_boot_params so
adding in one more is fine.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160119/0bc0e317/attachment.sig>