Is there a difference between the image that would be used to boot from USB and the image used to boot from SPI-flash?

[EdSutter]

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,

[EdSutter]

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...

[EdSutter]

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.

[raymondwang]

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

}

[EdSutter]

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

[raymondwang]

  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.

[fabio_estevam · Accepted 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

[EdSutter]

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

[fabio_estevam]

Hi Ed,

Yes, mx6 uses USB as fallback method.

Regards,

Fabio Estevam