How to debug boot process of VF6xx?

[adamszalkowski]

I have set BOOT_MODE[1:0] = 00 and BT_FUSE_SEL=1 and still the CPU ends up in the UART downloader.

Is there a way to debug or trace the decisions taken during the VF6xx boot?

[slw]

Do you have additional hardware connected to the BOOT_MODE-Pins ?

You should check the recognized BOOT_MODE, reading BOOT_REG-field in RCSR.

[adamszalkowski]

The SRC_SBMR2 register has a value of 0x11. This is almost as expected with the exception of SEC_CONFIG[0] which is 1, although this should not enforce secure boot.

[falstaff]

When the module is fused, the module tries to boot from the boot device defined in the boot fuses. If it can't do this, it falls back to serial loader. So the question is, is your boot device correctly configured and do you have a valid image on that boot device? You should be able to get the current boot device configuration by reading OCOTP_CFG4 (0x400A5450).

Also note the file attached in the Reference Manual PDF called Fuse-RCON Mapping.xlsx (not available in Rev. 7, but it is there in Rev. 5).

[antoniojenkins]

Can someone share their fuse settings for eMMC?  I've experimented with the following and am having no luck.

1. BOOT_CFG2: 0x40

    BOOT_CFG1: 0x70

2. BOOT_CFG2: 0x40

    BOOT_CFG1: 0x78

3. BOOT_CFG2: 0x40

    BOOT_CFG2: 0x7A

4. BOOT_CFG2: 0x42

    BOOT_CFG2: 0x7A

My bank 0, word 6 is set to boot from fuses: 0x00000010

My eMMC can be read/written/erased from the uboot that is put into ram by the mfgtool.  I have re-built it to give a longer bootdelay, thus letting me preventing the fall through to the usb gadget driver code and use uboot normally.  I have verified that the image on the eMMC looks good (it is just uboot for now).

One thing that I am not doing is partitioning the eMMC, but I don't think this needs to be done - the uboot image (.imx file) just needs to live at the 1k offset in eMMC.  Can anyone comment on this?

Thanks,

Antonio

[billpringlemeir]

You should probably start another thread on eMMC boot.  I think that you definitely need to partition the boot areas on the eMMC.  The SDHC bus will run different cycles for 'boot' mode than a normal eMMC read.  The boot partition is known to be consecutive and the boot protocol will stream the data from the 'boot' partitions.  A normal eMMC protocol is different than that used during boot.  You should get the JEDEC spec on eMMC which gives definitions of all the commands.  You could attach a scope and/or an eMMC analyzer to the bus during boot to see what is going on.  The eMMC is much more complex that a NAND/NOR, etc.  There are dozens of configuration options and commands in the protocols.  The other devices are usually just a parallel read with a few commands to ID.  The eMMC is probably the most complex boot device available on the Vybrid.

[antoniojenkins]

Thanks for the response.  Funny how things workout.  Only minutes after my post I was able to get another board to boot just fine from eMMC.  My main problem was the image (u-boot.imx).  It was not good.  So, my original attempts at booting it with the fuses set to group 1 (in my previous post) were not successful due to the image, not the fuse settings.  I took the wrong path in experimenting with fuse settings rather than fixing my image.  After I fixed my image I had no chance of succeeding due to my messing around with the fuse settings.  I pulled out another fresh prototype board yesterday, set the fuses as in group 1, let the mfgtool's usb gadget code burn my "good" image into eMMC, and bingo, it booted from eMMC on the next power cycle.

So, for those interested, here's my setup for getting u-boot to boot from eMMC:

Chip:                        eMMC version 4.5

Vybrid Connection:    ESDHC0

Vybrid Fuses:            Bank 0, Word 5 = 0x00004070

                                Bank 0, Word 6 = 0x00000010

U-boot image:            Modified for my board from the u-boot-src (7/2013) that ships with the mfgtool.  It's original target is the tower board (vf610).

Partitions on eMMC:   Not necessary for u-boot, just put the u-boot.imx file at 1k offset from beginning of eMMC main partition.

NOTE:  I am not sure if the mfgtool is burning my u-boot image into a boot partition on the eMMC, or the user parition.  Given the information in the Vybrid RM and the way the fuses are set, it seems like the eMMC4.3> special boot mode is being used in my case.  This leads me to believe that one of the eMMC boot partitions is being used, but I don't think the mfgtool is burning my image into one of the boot partitions.  The RM shows a flow chart that seems to end up booting from the user partition if things are not setup properly to boot from a boot partition.

[karina_valencia]

Timesys Support can you help to  provide some code samples?

[karina_valencia]

timesyssupport any  update?

[timesyssupport]

Hello Karina,

Unfortunately, as we mentioned in the previous case, we do not have any code samples for this.

Thanks,

Timesys Support

[billpringlemeir]

Get the HABV4 API document (officially, High Assurance Boot Version 4 Application Programming Interface Reference Manual); which maybe under restrictions.  You can use the SRCE (status reason configuration error) command to get some information on the last HAB failure.  See appendix A of the HABV4 API document.  Also, section 19.8.3.1.4 ERROR_STATUS of the Vybrid Software Programmers Reference v7 has some information.  I believe this is the same SRCE, but the documentation is not clear.

[adamszalkowski]

Do I still get HAB events even in Open configuration?

[billpringlemeir]

You can definitely run the ERROR_STATUS  command with the serial/USB protocol in Open configurations.  Unfortunately, I haven't actually used it so I am unsure if it is the same as the HAB document or something different.  The HAB reasons handle open configuration issues such as 'invalid ivt', 'invalid dcd', etc.  Often there is an over-lap and it only gets included in the secure documents.  Probably only someone from FreeScale can answer or you can get the documents and read the values.