* [U-Boot] AM335x SPI boot not working
@ 2015-12-16 14:34 Lars Poeschel
2016-01-14 21:01 ` Tom Rini
0 siblings, 1 reply; 4+ messages in thread
From: Lars Poeschel @ 2015-12-16 14:34 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* [U-Boot] AM335x SPI boot not working
2015-12-16 14:34 [U-Boot] AM335x SPI boot not working Lars Poeschel
@ 2016-01-14 21:01 ` Tom Rini
2016-01-18 9:02 ` Lars Poeschel
0 siblings, 1 reply; 4+ messages in thread
From: Tom Rini @ 2016-01-14 21:01 UTC (permalink / raw)
To: u-boot
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>
^ permalink raw reply [flat|nested] 4+ messages in thread
* [U-Boot] AM335x SPI boot not working
2016-01-14 21:01 ` Tom Rini
@ 2016-01-18 9:02 ` Lars Poeschel
2016-01-19 16:01 ` Tom Rini
0 siblings, 1 reply; 4+ messages in thread
From: Lars Poeschel @ 2016-01-18 9:02 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* [U-Boot] AM335x SPI boot not working
2016-01-18 9:02 ` Lars Poeschel
@ 2016-01-19 16:01 ` Tom Rini
0 siblings, 0 replies; 4+ messages in thread
From: Tom Rini @ 2016-01-19 16:01 UTC (permalink / raw)
To: u-boot
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>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-01-19 16:01 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-16 14:34 [U-Boot] AM335x SPI boot not working Lars Poeschel
2016-01-14 21:01 ` Tom Rini
2016-01-18 9:02 ` Lars Poeschel
2016-01-19 16:01 ` Tom Rini
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.