Has anyone booted the Vybrid from SPI0? We can read and write to our serial NOR flash and have UBOOT loaded on it.

[admin]

Boot_CFG4 = 01001000

Boot_CFG3 = 00000000

Boot_CFG2 = 00000000

Boot_CFG1 = 00100000

BM1 = 1

BM0 = 0

[RossMcLuckie]

Mike,

What hardware are you using, your own or the TWR?

Have you looked for any activity on the hardware pins to see if the processor is even trying to access the device?

You might want to re-chack your setting on CF4, you seem to be set bit 6, which has no relevance, my assumption you are trying to use CS2, this would be bit 5.

Other settings suggest SPI0, 24-bit addressing.

If selection of CS2 is not the problem here, please confirm your hardware configuration, that you have seleceted all the correct IOMUX pins as detailed in the RM and whether you see any activity on any of the SPI0 pins as you try to boot.

Thanks

Ross

[admin]

Hi Ross,

We are using our own design. It’ll boot off SD card, Uboot, then run Linux.

Have only looked at CS0, no activity. There is activity on CS0 when reading and writing to this part, reading and writing to this part works. We are using Winbond W25Q80BVSNIG serial NOR Flash.

The reason we set bit 6 in CFG4 was we thought that if we left the vybrid configured to boot from SD card and removed the SD card it would fall back and boot from SPI0, but it didn’t.

Yes, SPI0, 24 bit addressing.

We just got done verifying all the pertinent RCON pins just to make sure they are loaded correctly, it appears they are.

Thanks,

Mike

[RossMcLuckie]

Mike,

Sounds like you might have got a little mixed up over serial downloader mode and booting from seriel ROM. If the boot process fails (i.e. set to boot from SD with no SD card) the boot ROM will default to serial downloader mode, which would normally be defined by the BMODE[1:0] pins.

CFG4 bit 6 wouldn't have anything to do with this and to boot from SD the key configuration to select the high level interface would be done in CFG1.

If you are seeing no activity on CS0, but you do in normal runtime then it would suggest you still have an issue in your initial set up.

Have you confirmed you are using the correct IOMUX pinout for SPIO usage, see table in RM, boot ROM chapter.

You might also want to trying using a debugger to see what mode the processor thinks it is in after a power on, see the SRC registers (SBMR1/2) which latch the values the processor is using to attempt to boot with.

Ross

[admin]

Ross,

We’re going by the diagram in the RM, p.823, at the decision block “Primary Boot Device is I2C/SPI? No, so “Download and Authenticate Image from Serial EEPROM”. Seems like it should try to boot from serial EEPROM, then if that fails then try USB/UART. Checking on IOMUX…

Mike

[RossMcLuckie]

Hi Mike,

Ok, you were trying to use the recovery mode, I understand, but if the CFG1 pins were set up for serial mode this wouldn’t be valid, so again I assume you change CFG1 to SD boot to try this, but no real difference between this and trying to boot from serial as primary device, so either both would work or neither, so suspect issue lies elsewhere at this time.

Ross

[admin]

Ross,

We are booting from SPI0 now. The boot image needs to be at a 1024 byte offset from the base of the SPI flash device. I think we are in good shape.

Thanks,

Mike

[RossMcLuckie]

Thanks for the update Mike and glad to hear you are up and running now.

Ross

[admin]

Yes, we changed CFG1 to SD to test the fallback mode.

We made a significant discovery, RCON24 doubles as nFLASH_RB after boot. Happens to have a 4.7K pullup. There’s also a 10K pulldown RCON resistor on that net. We removed the pull up and now are getting activity on SPI0, we were inadvertently selecting SPI1, or so it appears. However, even with all this activity now on SPI0 it’s still not booting. I think we’re closer.