AM6442: place SBL bootloader to emmc0

Hello,

Frank Gottschalt said:

--flash-writer=sbl_prebuilt/am64x-evm/sbl_uart_uniflash.release.hs_fs.tiimage
--file=tiboot3.bin --operation=flash-emmc --flash-offset=0x0

After flashing with this method, could you please configure primary bootmode as eMMC alternate and secondary as None. More specifically, following should be the bootmode pins positions.

B0-B7 : 11010010, B8-B15 : 00000000

Regards,

Prashant

I'll try this emmc0 bootcfg configuration without secondary bootmode tomorow.

In the meantime, I have accidentally discovered the following behavior in the emmc0 UDA boot mode that was last set:

I had last placed a copy of my tiboot3.bin on a FAT32 partition on emmc0.
The primary boot mode emmc0 UDA is set as in my first post.
The following behavior now: if I now switch on the EVM board without the SD card inserted, nothing happens. If I insert an SD card or if it is already inserted when switching on, tiboot3.bin is apparently loaded and executed by emmc0. But only if an SD card is inserted. Very strange.

By the way, even with the deactivation of the secondary bootcfg on, this behavior “boot from emmc0 only if SD card is present” is still present (B0-B7 : 11000010, B8-B15 : 10000000).

A tiboot3.bin on the SD card is then ignored.

I discovered this behavior by chance after changing my tiboot3.bin (new version) on the SD card, as my old version was still placed on emmc0.

Ultimately, we want to boot primarily from emmc0, but the SD card should only be used here as an option for updating firmware. Our tiboot3.bin should primarily load and start an application image on the SD card or be able to overwrite, load and start an image from emmc0.

Frank Gottschalt said:

By the way, even with the deactivation of the secondary bootcfg on, this behavior “boot from emmc0 only if SD card is present” is still present (B0-B7 : 11000010, B8-B15 : 10000000).

This bootmode configuration is not correct.

I have just tested booting successfully from eMMC FAT partition with no SD card present. The boot configuration is => B0-B7 : 11000010, B8-B15 : 00000000

[11:49:39.063] U-Boot SPL 2023.04-dirty (Aug 01 2024 - 11:46:12 +0530)
[11:49:39.095] Resetting on cold boot to workaround ErrataID:i2331
[11:49:39.099] Please resend tiboot3.bin in case of UART/DFU boot
[11:49:39.102] resetting ...

[11:49:39.989] U-Boot SPL 2023.04-dirty (Aug 01 2024 - 11:46:12 +0530)
[11:49:40.020] SYSFW ABI: 3.1 (firmware rev 0x0009 '9.2.8--v09.02.08 (Kool Koala)')
[11:49:40.052] am642_init: spl_boot_device: devstat = 0x43 bootmedia = 0x9 bootindex = 0
[11:49:40.056] SPL initial stack usage: 13408 bytes
[11:49:40.100] am642_init: spl_boot_device: devstat = 0x43 bootmedia = 0x9 bootindex = 0
[11:49:40.104] Trying to boot from MMC1

Prashant Shivhare said:

Frank Gottschalt said:

--flash-writer=sbl_prebuilt/am64x-evm/sbl_uart_uniflash.release.hs_fs.tiimage
--file=tiboot3.bin --operation=flash-emmc --flash-offset=0x0

After flashing with this method, could you please configure primary bootmode as eMMC alternate and secondary as None. More specifically, following should be the bootmode pins positions.

B0-B7 : 11010010, B8-B15 : 00000000

I have now tested your suggestion. Unfortunately, this variant does not run the SBL placed on the emmc0 at all. Not with the SD card inserted nor without the SD card.

Frank Gottschalt said:

I have now tested your suggestion. Unfortunately, this variant does not run the SBL placed on the emmc0 at all. Not with the SD card inserted nor without the SD card.

At least you don't see the weird behaviour anymore which was probably caused by setting HIGH the reserved B8 pin.

Could you try the eMMC alternate bootmode as previously suggested?

Prashant Shivhare said:

This bootmode configuration is not correct.

I have just tested booting successfully from eMMC FAT partition with no SD card present. The boot configuration is => B0-B7 : 11000010, B8-B15 : 00000000

Fullscreen

I also tested your suggestion of this bootcfg. But always its running the placed \emmc0\tiboot3.bin file only from ROM bootloader, if there a sd card is present.

As a precization: I am currently using the TI Am64x EVM-B board (PROC101C(004)) with the actual silicon release of your cpu for these tests. Our own SOM is in preproduction of a second zero series now without the possibility of easy to switch bootcfg-pins.

Frank Gottschalt said:

But always its running the placed \emmc0\tiboot3.bin file only from ROM bootloader, if there a sd card is present.

I am not sure what is the inconsistency here?

Frank Gottschalt said:

The boot configuration is => B0-B7 : 11000010, B8-B15 : 00000000

This boot configuration is supposed to boot from eMMC UDA FAT partition which is what you observe, right?

Prashant Shivhare said:

Could you try the eMMC alternate bootmode as previously suggested?

I allways tested this without any success at all and replied this allways to you. Is there a necessity to create a boot partition with a running Linux or is the uart-uniflash example sufficient for create such a raw boot partition?

Prashant Shivhare said:

This boot configuration is supposed to boot from eMMC UDA FAT partition which is what you observe, right?

I want to find a solution for booting the SBL from emmc0 at all. I tried now both, the eMMC alternative Bootcfg and the eMMC UDA FAT Bootcfg. But meanwhile only in eMMC UDA FAT I had have a success at all, but for now only with plugged SD card. In alternative Boofcfg there was no boot possible at least.

Our goal is to have emmc0 as primary boot device. The app-image will be placed, loaded and runs then also from inside of emmc0. The SD card is used then only as optional device for updating firmware or as a backup device in the event of a fault. Therefore the SD is planned as secondary boot device in case the Bootloader isn't present in emmc0 anymore (in case of a fault) or at the first commissioning of every board. Normaly there isn't a SD card present here for running the application. And there will be no switchable Bootcfg-pins at our SOM. This bootcfg will be fixed by some placed resistors from production.

Secondly, we would also like to use emmc0 as a drive in the application. However, we do not want to touch the partition with tiboot3.bin and the appimage. The application should never be able to write to the boot partition and should only have write access to a second user partition for not to be able to destroy/crash the boot partition.

In an older application at AM335x I used a NOR-Flash as primary boot device and the SD Card as secondary boot device. Here I placed the SBL at the begin of the NOR-Flash by writing it RAW to the NOR-Flash at Sector0. The application image was written also in RAW after that SBL region in NOR-Flash at a higher sector offset. In application and SBL I used a FAT FS lib beginning with an even bigger sector-offset away from SBL and appimage regions in the NOR-Flash too.

In the AM64x project the primary boot device should be the emmc0 now instead of a NOR-Flash. Other primary boot devices are not useable for us. Behind the OSPI interface there is an EEPROM (another type as the OSPI EEPROM inside the EVM board), but this one is used for booting up a FPGA, also from sector 0 at this EEPROM. I2C EEPROMs as last solution are limited to 2Mb in Size, but the needed SBL takes more memory than this 2Mb! Here a 4Mb I2C EEProm would be needed. The SPI is also not useable, because we don't have a SPI EEprom designed at our SOM and we will need the SPI bus for other applications.

Prashant Shivhare said:

I am not sure what is the inconsistency here?

Tomorrow I will test the eMMC UDA FAT Bootcfg case again at a second EVM Board to excluse a failure with my EVM.

Prashant Shivhare said:

This boot configuration is supposed to boot from eMMC UDA FAT partition which is what you observe, right?

Correct. This was with the eMMC UDA FAT partition. But the boot process will start only if a SD card is still present or in a range of some seconds after switching on, if I press a SD Card into the slot.

Is there a possbillity to clear the emmc0 drive from any partition to delivery status with FAT FS oder MMCD driver? It seems to be only have functions for creating partitions, but not for clear partitions and or the drive.

I have now done another test of eMMC UDA FAT Bootcfg with taped pins of the SD card with a very thin insulating foil of a few micrometers. The idea was to test if the SD Card present-IO-Signal can be a trigger for the ROM-Bootloader for loading and running the emmc0 SBL. 
However, I had no luck that way. The ROM bootloader apparently reads from the SD card and expects to find a real partition or at least a real device there before executing the primary boot. That would be an extremely big bug in the ROM bootloader. 

Frank Gottschalt said:

Tomorrow I will test the eMMC UDA FAT Bootcfg case again at a second EVM Board to excluse a failure with my EVM.

short note: also on a second Ti EVM board the ROM bootloader in emmc0 UDA FAT bootmode shows the same symptoms, that the ROM bootloader first waits "forever" for the insertion of an SD card, and only then loads and executes the SBL of emmc0.

This seems to be a very unpleasant bug of the ROM bootloader.

Now, it seems, that the alternative emmc0 bootmode can be the only way out? But how I have to format and create a partition and place the SBL in right way to work? May be onle with a linux and U-Boot/parted tools?

another short note (it's getting better and better (attention: sarcasm)): even with the SBL bootloader placed in OSPI-flash and then in boot mode xSPI (B0-B7 : 11001110, B8-B15 : 01000000) the ROM bootloader shows exactly the same symptoms, that this ROM bootloader first waits "forever" for an SD card to be inserted, and only then loads and executes the SBL from OSPI.

It seems to be a very general bug of the ROM bootloader that an SD card is always expected.

Hello,

I do not think there is any ROM bug here. The issue you are describing is so basic that it would have been caught in internal testing even before the part number was first released. Also, we have been using the different bootmodes for years independent of the SD card and it always works just fine.

So, I highly believe there is something wrong with the setup on your end.

Regards,

Prashant

You were right!

In fact, the ROM bootloader had already started the SBL and this now leads to this behavior within the mmcsd_v0.c within the function MMCSD_initSD(..) indirectly called by the Drivers_open():

mmcsd_v0.c line 760 of function MMCSD_initSD():

                   /* Wait for card detect */
                   while(!MMCSD_halIsCardInserted(attrs->ctrlBaseAddr));

This means that this location is not in the ROM bootloader, as I first assumed. This is reassuring for me, as I can now fix the driver for us inside the SBL at this point because the SD card is optional. Inside of application images with an SD driver included this behavior will be also occur! The sd card is never an optional device in your drivers implementation.

In the meantime, I was able to understand the hardware partitioning of emmc devices and now suspect that the emmc0 RAW bootmode and emmc0 alternate bootmode are also based on the two hardware boot partitions boot#1 and boot#2, which are opened with the function

MMCSD_enableBootPartition(MMCSD_getHandle(0), 1);
or
MMCSD_enableBootPartition(MMCSD_getHandle(0), 2);

The calls of MMCSD_enableBootPartition(MMCSD_getHandle(0), 1);
are also placed in the sbl_uart_uniflash... program directly before flashing these memory areas using Bootloader_MmcsdRaw_writeToOffset().

I am now clarifying whether I can also use the emmc0 RAW bootmode or the emmc0 alternate bootmode. If this still works, my problem would be completely solved.

I closed now the other thread as resolved because it is not a problem anymore. But there is always this little sub problem with the Drivers_open() of emmc0 device if this will called from SBL and the App twice:

Addon: Your MMCSD drivers seem to have the unpleasant effect that the Drivers_open() in the application hangs as soon as you have already used the emmc0 driver in the SBL bootloader and now also include this in the application. The second initialization of the MMCSD driver on emmc0 seems to have a problem here (SDK: v9.1.0.41) of a hanging Drivers_open() inside of the mmcsd-driver. There is no problem on the sd0-device. The double initialization works here with the sd-device. But the multiple init of emmc0-device seems to generate a problem here in the second attempt.

The MMCSD dual init problem of the emmc0 drive is now a stopper for me.


inside the MMCSD_initEMMC function the second MMCSD_transfer function will never return. The retry variable will never be used in this case.


static int32_t MMCSD_initEMMC(MMCSD_Handle handle)

{

.....

/* Controller initialization done, moving to card init */
if(SystemP_SUCCESS == status)
{
/* CMD0 - reset card */
MMCSD_initTransaction(&trans);
trans.cmd = MMCSD_MMC_CMD(0);
trans.arg = 0U;
status = MMCSD_transfer(handle, &trans);
}

/* Sleep for 5ms for input clock frequency, as mentioned
* in JEDEC standard JESD84-B51 section 10.1
*/
ClockP_usleep(5000);

if(SystemP_SUCCESS == status)
{
/* OCR query */
uint32_t hostOCR = 0U;

/* Sector mode */
hostOCR |= (2U << 29U);

/* 1.7-1.95 VDD support */
hostOCR |= (1U << 7U);

/* Busy bit set */
hostOCR |= (1U << 31U);

if(CSL_REG64_FEXT(&pReg->CAPABILITIES, MMC_CTLCFG_CAPABILITIES_VOLT_3P3_SUPPORT) == TRUE)
{
/* 2.7-3.6 VDD support */
hostOCR |= (0x1FFU << 15U);
}

/* High Speed support bit set */
if(CSL_REG64_FEXT(&pReg->CAPABILITIES, MMC_SSCFG_CTL_CFG_2_REG_HIGHSPEEDSUPPORT) == TRUE)
{
CSL_REG32_FINS(&pSSReg->CTL_CFG_2_REG,MMC_SSCFG_CTL_CFG_2_REG_HIGHSPEEDSUPPORT, 1);
}

/* Poll until card status bit is powered up */
uint32_t retry = 0xFFFFU;

MMCSD_initTransaction(&trans);
trans.cmd = MMCSD_MMC_CMD(1);
trans.arg = hostOCR;

status = MMCSD_transfer(handle, &trans);
if(SystemP_SUCCESS == status)
{
while(((trans.response[0] >> 31)==0) && (retry != 0))
{
status = MMCSD_transfer(handle, &trans);
retry--;
}


This happens only if the emmc0 drive driver was uses twice. Once in the SBL Bootloader and in the application too. Then the first Drivers_open is going well, the second one inside the application is going to hangs here.

I've found another thread, you was questioning the exact questions which are fitting to my problem here: e2e.ti.com/.../4703643

I've solved the other problem with the non optional SD card by changing the sd-card driver init slightly.

I have now solved this emmc driver problem with a hack. I am now using the running emmc0 driver within SBL code from our application with calling the function pointers of the MMSCD driver within SBL memory in lower MSRAM.
This way I avoid the second initialization of the EMMC0 driver in the application. This works for the time being, even using the FAT file system, but is not very clean.

I can now load and run my SBL bootloader from the OSPI memory, from SD card, as well as with the EMMC0 UDA bootmode (file io).
However, I still cannot use the EMMC0 RAW boot mode. Something is wrong with the TI flashing tool, I'm afraid.