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