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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
