Hi.
This might be a stupid question.
I assume that the Sabre Lite board is using the SPI flash to start the u-boot?
If so, is it possible to put some boot code in the internal memory to start up a Linux image (running my image from a SSD drive or a SD card).
Or do I need to have a SPI flash to be able to load the u-boot?
Is it possible to boot direct from a SATA interface and include the u-boot in the SSD drive?
Thanks,
Niklas
I think it's possible to boot from SATA directly.See details in System Boot chapter Boot Devices.
IVT offset for SATA is also 0x400. So program uboot.bin in 0x400 for SATA boot and change BOOT setting to SATA.
In my opinion ,SPI flash can be as secondary boot device.
What I could understand from the BOOT section in the document. To boot from a SATA, I need to use the BOOT_CFG1[7:4] bits to set that I want to boot from the SATA?
Are these bits used when booting in eFuse mode or do I always have to start in "Internal mode" to use these bits?
So if I want to be able to boot from either SATA or SD card, I probably have to use some type of SPI flash where it starts the u-boot, which then starts the image on the desired device (SATA or SD card)?
As a brief :
1. boot from fuse mode always check CPU's Fuse setting to decide which device as a boot device;
2. serial downloader mode always enter MFG mode in despite of Fuse setting or GPIO override setting;
3. internal boot mode can use external GPIO setting to override fuse mode setting,so it's alternate setting to change boot device without
change Fuse setting (Fuse setting is OTP)
Mode 1 and Mode 3 are behavior of eFuse Config BT_FUSE_SEL not blowed. See below table for details.
It means a flag of Fuse setting is valid or not for CPU BOOT ROM ( I guess that)
So for you application, I assume no Fuse settings was blowed, If you want to boot from SATA,
Step 1: change boot mode to internal boot mode;
Step 2: Change GPIO default setting mapping to BOOT_CFG1 BOOT_CFG2 BOOT_CFG3 BOOT_CFG4
These 4 BOOT_CFGs are 8bit setting ,totally 32bit and mapping to 32 GPIO setting.
BOOT_CFG1 should be 0x20
BOOT_CFG2~BOOT_CFG4 setting should be set per you application.
Thanks for the update.
Makes sens that BOOT_CFG are used in booth cases.
But I assume that if I use the BOOT_CFG to boot from SATA, I can only use SPI flash or USB as "fallback"?
If I want to be able to first try to boot from SD card and if it's not there, it should boot from SATA. Then I probably need to run a u-boot in a SPI flash and then from there try to boot the image on a SD card (if the SD card is not there, try to boot from SATA).
The idea is that the the image should be running from a SSD drive, but the user should be able to start up an image from a SD card in case some stuff needs to be updated.
In this case, the boot from the SD card needs to have higher priority than the SSD drive.
Another question,
Do you have experience with production of the MX6. What is the best way to initialize the processor in production?
Is it via USB or pre-program the SPI flash etc.?
Thanks,
Niklas
1.Sorry no mass production experience on MX6. We are developing based on that only.
2. According your design idea, you wanna a secondary boot if booting from SD card failed.
In MX6 RM ,chapter system boot,there is detailed description on MX6 BOOT ROM behavior.
From that, we know MX6 support recovery device but only I2C or SPI devices. So for your fallback
design, you can set default boot device to SD card,if it's failed ,recovery device i2c or SPI flash will
be secondary boot device. So SD card has higher priority boot sequence.
To covering your image loading from SD card or SATA, your bootloader (uboot) is the 2nd stage bootloader.
you can add more robust feature to loading image per your favorite sequence (SD card,SATA, or more others )
You may notice that I split the boot device and image host device to different scope. I may be the same one or
different one.
3. For MP, we advice SPI flash is pre-programmed.