Serial Boot Loader - UART

[andrewalexander]

I am working on getting the Vyrbid VF6xx to boot through UART in order to download our custom bootloader that has been developed previously (which works just fine when sending the image through DS-5). I currently have a working TeraTerm TTL script to interface through the SDP and can associate, read registers, and write a file to a location. What I have been unsuccessful in doing is being able to actually boot an image. I have realized that I need the image to be formatted with an IVT and DCD header, and that is where I have gotten stuck. Currently, we have an elf32-little image that I know contains some of the DCD and must also contain the IVT, but I am having difficulty in parsing it and translating it to an image that the SDP can understand and use. In the reference manual, there is information on what to include for these headers, but I do not see those headers anywhere in the elf32 image. I was led to believe that the elf32 image SHOULD have these headers, and that is how it knows to set up DDR and flash locations, etc. (the point of the DCD...) The fact that these headers are missing when I inspect the elf32 image leads me to believe that the image does not actually set up any of the memory or flash data, but is instead handled by DS-5 or some other IDE sending the image (it also works using j-link in SourceryCodebench).

What I am asking for is some kind of a template or a step-by-step guide to generating an image that is recognizable by the bootROM when transferred through the SDP via UART.  If this entails editing the elf32 image or editing the pure binary image generated from the elf32 file, I just need to know what to include and where. I know this has been posted before in regards to USB, but the real problem for me is that I know the image works, and ideally I would just parse through the elf file, find the relevant memory addresses that we are using, and translate them into the IVT/DCD format that the BootROM expects.

Also, I noticed in some of the various communities posts that the memory location for executable code is slightly different than what Ihad originally thought. Currently, I am sending the image to the 0x3F040000 address, and once I send the image, I send the JUMP_ADDRESS command to start executing at 0x3F040000. I have been led to believe (through some related post) that only code that lives in the external RAM (0x80000000) can be executed. Is this correct? And if so, how would I go about transferring the executable to that location? Would it just be a subsequent WRITE_FILE command?

Thank you in advance for your time and effort in helping me to resolve this issue. I look forward to a reply.

GordyCarlson

[valterm]

Ciao Andrew,

the boot ROM can't parse an ELF file, you should provide a raw binary file and know the address of your executable's entry point. You will not have a stack set-up etc. so it will probably involve some assembly code.

I did that for Windows CE so I can't help you specifically on this point.

On the other side you can simply prepend the IVT header in front of your binary. Consider that it's better to load the code in the internal RAM (0x34f00000, reserving part of it for the stack etc.) if it's not too big. To load code in DDR you have to initialize the DDR using the DCD structure that can be appended to the IVT (check the "System Boot" chapter in the Vybrid's reference manual for a description of it) and then you'll be able to load code there.

Your serial loader will have to parse the DCD and send the appropriate SDP commands before loading your code in memory. It's worth appending the instruction to the IVT because you'll need to execute them also when you'll boot from NAND or SD (in that case the internal ROM will take care of parsing the commands for you). The SDP WRITE_FILE command can be used to transfer the IVT+executable code and then the JUMP_ADDRESS command to start the image. Be careful because the address you pass to the JUMP command must point to the IVT header, not to the actual entry point. The real entry point in code will be stored inside the IVT structure. Consider that the IVT will also need to be loaded in memory, so reserve some space for it. For example forcing your code to start from 0x34f01000 will give you 4KB for the IVT (you will actually need way less if you don't have many commands in the DCD section).

[andrewalexander]

Okay so I have some clarifying questions at this point.

We developed an apploader that, once loaded, can program itself into flash and it sets up all of the necessary DDR and QuadSPI modules through the proper DCD commands. Since that is the case, do I even have to worry about the DCD when sending in the image through serial? To give an outline of what we do now: we load in the apploader through a JTAG interface, it runs in RAM, and then we have a function within the apploader to send a binary to flash (it waits for the user to send an application, then when the user presses any key after sending, it executes the proper DCD commands). So, since this configuration is done within the app at that stage, is it necessary for me to include the DCD header when sending the original binary image (with IVT prepended)? I can definitely configure the IVT header now and add that to the image, but the DCD seems like overkill when the serial boot loader will only be used to program the initial image that will take over all the programming from there.

[timesyssupport]

Hi Andrew,

I don't believe you would need the DCD header in this case. I have not had extensive experience in this, however, so Freescale MQX Design team can confirm.

Thanks,

Timesys Support

[karina_valencia]

cyborgnegotiator can you add your comments on this case?

[cyborgnegotiato · Accepted solution]

Hi,

DCD item (absolute address of DCD image) in the IVT table is optional, it is no necessary (please read reference manual more carefully - Vybrid RM rev.F 19.6.1.1 Image Vector Table Structure)

Regards,

Jozef

[karina_valencia]

timesyssupport  can you  confirm if you  are  available to   help here?

[karina_valencia]

timesyssupport can you attend this case?