• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 3817 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MLO file format for Am335x

Mario Giovanni Casali
Intellectual 360 points
Other Parts Discussed in Thread: AM3359

Hello.

I'm trying to get my Sitara-based board to boot MLO from MMC0 (SD Card).
I've built my own 2nd-stage bootloader following StarterWare instructions (sys/bios sdk 1.0.0.8) and it works fine both during debugging and when booting from SPI Flash (SPI0); I know that because it sends ASCII message strings on UART2 and I can capture those strings using a terminal emulator; nonetheless, I cannot get it loaded from MMC0 and run.
Both bootloader_SPI.bin and bootloader_SD.bin are generated by isdk_image.exe (launched by post_build.bat), of course. 

If I copy to my SD card either Android MLO or Linux MLO prebuilt by TI, both of them are loaded and run (I can see their boot messages in a terminal emulator).
So, I compared my MLO and TI MLO's and found that the header in TI prebuilt MLO files is 200h byte long, while the header in my MLO is 8 byte long (as it is said on page 4146 of Technical Reference Manual and as it is for MLO file for IDK board prebuilt by TI).
It seems that on-chip booloader needs to be better documented in the technical manual ... 

I'm attaching a zipped .doc file containing dumps of MLO files
 4760.Some_dumps_of_MLO_files.zip.

Can somebody help me?
Thanks in advance.

Mario G. Casali
System Electronics
Italy

Post Scriptum:
I found somewhere in the forum that somebody had a similar problem and solved it just eliminating a "printf" in his source file; I cannot believe it's just because I too have "printf" in my MLO but
1) my bootloader works fine when loaded from SPI Flash and
2) looking with an oscilloscope at accesses to MMC0, it seems that MLO with 8 byte header are not loaded (and then not run).

  • 0
    Intellectual 360 points

    Just to add some more information ...

    Processor is Am3359;
    SD Card is connected to MMC0;
    Boot sequence is MMC0 - SPI0 - UART0 - USB0;
    I used both 2 GB SD Cards and 4 GB SD Cards;
    it seems that on-chip bootloader prefers SD Cards partitioned and formatted under Linux (a primary FAT32 partition and an extended partition); at least, using such cards causes on-chip bootloader not to start the bootloader_spi.bin previuosly flashed in SPI Flash ...

    Can anyone help me, please?

    Mario

  • 0 in reply to Mario Giovanni Casali
    Expert 1120 points

    A couple of comments (maybe they'll help):

    I've also found the SD card needs to be formatted in Linux. I've tried FAT32 formatting cards in Windows and the ROM bootloader refuses to accept them.

    Agreed the header documentation could use some improvement. When I had my bare-metal "hello world" program written under starterware, the only way I could get it running from an SD card was to use a hex editor (hxden) to copy & paste the header from a known working u-boot MLO file onto the front of my file.

  • 0 in reply to Frank Van Hooft1
    TI__Mastermind 26205 points

    Guys,

    I always had problems using the SD slot in my notebook to format SD cards, but when I used external USB to SD adapter, I was able to format and use the SD normally at either BeableBone or Starter Kit...

  • 0 in reply to Rogerio Almeida
    Intellectual 360 points

    Hi Rogerio.

    We do use USB to SD adapter (the one coming with IDK, to be more precise) and use the HP Utility suggested by TI (a newer version of it, to tell the truth); and SD Cards are not recognized by on-chip bootloader.

    Anyway, we followed the "printf" hint and succeded in booting our MLO from SD Card!

    We found that one cannot write instructions like

      UARTprintf("*   Word1: 0x%08X        *\n\r", HWREG(0x4030CE40));

    and neither like

      UARTprintf("*   Word1: ");
      UARTPutHexNum(HWREG(0x4030CE40));
      UARTprintf("        *\n\r");

    but only like

      unsigned int reg = HWREG(0x4030CE40);

      UARTprintf("*   Word1: ");
      UARTPutHexNum(reg);
      UARTprintf("        *\n\r");

    I've not yet looked deeply into generated assembler code and I can (hardly) understand there might be some problem in passing a "volatile" value (as HWREG(x) is) to a function, but I cannot understand the reason why the same binary file (just different in endian-ness) perfectly worked when loaded from SPI Flash and run in the same on-chip ram memory!

    I would like to understand what is allowed and what is not, since these misteries make one spend a lot of time ...

    Bye.

    Mario