I had been using SABRESD u-boot-2009.08 (from LTIB) and I was able to download the u-boot.bin file
through usb (using boundary-device's free imx_usb tool) to boot a board with the SD card removed
(our real system will not have an SD card, it will boot from SPI-flash).
Then I added a second SPI-flash device to ECSPI5 (bootable spi) and I was able to load the exact
same u-boot.bin image into the SPI-flash. When I changed the boot pins to boot from that device,
it worked just fine. That confirmed my assumption that the exact same binary can be used whether
I'm booting raw from USB or SPI-flash.
So far so good...
Since then I've transitioned over to the latest uboot (u-boot-2013.10), got all the same SPI
drivers working so that I can take the same image (now called u-boot.imx) that I boot off USB and burn
it into SPI-flash (to boot from SPI). I'm no longer able to boot from SPI using the same image that I use
to boot from USB.
I've verified that the data is properly loading into the SPI-flash, so I *thought* I should be able to use
the exact same image.
Has anyone else tried this? Is my assumption about the images correct?
Thanks in advance,
Solved! Go to Solution.
Ed,
u-boot.imx should be flashed at 0x400 offset when booting from SD card:
sudo dd if=u-boot.imx of=/dev/mmcblk0 bs=1k seek=1; sync
(This is explained at the the doc/README.imximage file:
git.denx.de Git - u-boot.git/blob - doc/README.imximage )
When booting from SPI flash and SD card the ROM starts reading from 0x400 offset.
Regards,
Fabio Estevam
Starting to investigate this, it appears that the 0x400 byte offset that is in the older version of u-boot.bin
which was established in the file flash_header.S of the older uboot build is no longer there.
Looks like the image now uses a new option to the mkimage tool "imximage" to create this instead of
having it built into the boot code as it was in the older version of u-boot.
Not sure if this is the problem, but I'm in pursuit...
Ok, I definitely need an explanation for this one...
Comparing the binary u-boot.imx with the older u-boot.bin from LTIB's uboot I notice (as I said above) that the 0x400 byte
offset is not in the image; as specified in the iMX6 reference manual section 8.6.1 "Image Vector Table and Boot Data".
If i understand this correctly, the bootrom is expecting the IVT to be at a 0x400 byte offset from the base of the image.
This offset is not in u-boot.imx. So, taking a shot in the dark, I prepended the u-boot.imx file with 0x400 bytes of zeroes.
NOW IT WORKS!!?? Whats up with that? It makes sense to me that this offset is needed, but how are other folks using this?
I'm updating this reply because I've also confirmed that the u-boot.imx file that is built does not boot when installed on
an sd card either. If I use the file that has the 0x400 byte offset, then it boots.
I think you misunderstand the difference between iMX6 IVT offset 0x400 and uboot building offset 0x400.
Firstly.iMX6 only can support booting device with specified offset (device type dependant, e.g eMMC is 0x400).
Secondly,FSL uboot building generated an extra 0x400 dummy padding bytes before IVT offset.
Unfortunately,MFG tool and fastboot only support flashing pure content (with out padding bytes). So we have to
cut off padding bytes from generated u-boot.bin.
For fastboot what I often used to debugging,I add a patch to support u-boot.bin with padding bytes or not). You can
touch it as a refer. This patch will check this is padding uboot or not and flash to proper offset of booting device.
//only apply for SD/MMC boot device
static void patch_on_bootloader(char* source,char* dest,char *length){
unsigned char* source_buf=simple_strtoul(source, NULL, 16);
unsigned int dest_start = simple_strtoul(dest, NULL, 16);
int no_padding=0;
//dest normally pointer to dest device partition start sector
if(source_buf){
//check if there is padding of source image
if((source_buf[0]==0xD1)&&((source_buf[3]==0x40)||
(source_buf[3]==0x41)))
no_padding=1;
}
//we should change dest for padding or not
if(dest_start){
//should step on padding bytes
if(!no_padding){
sprintf(source,"0x%x",source_buf+0x400);
}
}else{
if(no_padding){
//jump over dest in 0x200
dest_start+=0x400/MMC_SATA_BLOCK_SIZE;//
sprintf(dest,"0x%x",dest_start);
}
}
//ignore length since it's calculated freely
}
Raymond,
Yea, my impression of all this was that the 0x400 offset was just some requirement put on by the rom-bootloader in the iMX6.
Not sure where this snippet of code would be used in fastboot, but I simply dumped the content of the file (u-boot.imx) using
'od' to essentially do what your code does.
Don't know much about 'fastboot', but AFAIK, this applies only to Android, correct?
Ed
I don't think fastboot can only be for android based devices. My patch is for correct putting FSL uboot.bin to proper offset.
Sometimes FSL u-boot.bin should be flashed without 0x400 padding bytes,so using below command to remove padding
bytes:
sudo dd if=u-boot.imx of=/dev/mmcblk0 bs=1k seek=1; sync
With my patch,fastboot can check this uboot has padding bytes or not.
Ed,
u-boot.imx should be flashed at 0x400 offset when booting from SD card:
sudo dd if=u-boot.imx of=/dev/mmcblk0 bs=1k seek=1; sync
(This is explained at the the doc/README.imximage file:
git.denx.de Git - u-boot.git/blob - doc/README.imximage )
When booting from SPI flash and SD card the ROM starts reading from 0x400 offset.
Regards,
Fabio Estevam
Fabio,
Thanks for the pointer to that README. FWIW, it says that all iMX devices can boot from UART as a fallback.
I don't think that's the case for the iMX6 is it? I'm pretty sure that the fallback for iMX6 is USB (i use the imx_usb
tool from Boundary devices with my sabresdb board). I really wish it did support UART mode (I prefer simplicity),
so if it does, please reply!
Ed
Hi Ed,
Yes, mx6 uses USB as fallback method.
Regards,
Fabio Estevam