[U-Boot] AM335x SPI boot not working
Lars Poeschel
poeschel at lemonage.de
Mon Jan 18 10:02:32 CET 2016
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
More information about the U-Boot
mailing list