Spartan-6 / OMAP-L138 Co-Processing Kit

[sergios_]

Hello all,

I have one question related to the bootloader. Why is not available the bootelf command in the RidgeRun u-boot? Is it possible to build the bootloader with support for that command? I would like to boot an elf executable stored in flash when the system is powered on.

Best regards.

[JohnW · Accepted solution]

Hi,

It is possible to build U-boot with the bootelf command.  We haven't tested or used it, but you are welcome to!

I think all you need to do is go into bootloader/u-boot-2009.01/src/include/configs/da850_evm.h and add the following line:

#define CONFIG_CMD_ELF 

This probably can go anywhere in the file, and it turns on the bootelf command.  We use the da850_evm.h file, patched, instead of creating/maintaining our own board config header file.  DA850 = OMAPL138.

Then you can run this from the SDK root in order to build u-boot:

make bootloader

It shows up in images/bootloader and images/bootloader.spibin

Warning - if you completely erase the SPI flash to reprogram u-boot, you'll erase the MAC address which is stored in the last 64KB block.

John

[sergios_]

Hello John

I have followed your instructions and built again the bootloader after adding "#define CONFIG_CMD_ELF". Now I have the bootelf command. My problem is that when I try to run an ELF using bootelf I get something like this:

AVNET u-boot # bootelf 0xc0700000

Loading .vector @0xc0000000 (176 bytes)

Clearing .probe_agent @ 0xc00000b0 (32 bytes)

Loading .text @ 0xc00000d0 (515696 bytes)

Loading .syscall @ 0xc007df40 (8 bytes)

Loading .interfunc @ 0xc007df48 (4 bytes)

...

## Starting application at 0x00000000 ...

So now I'm trying to understand why u-boot tries to start the application at address 0x00000000 instead of address 0xC0000000. I don't know if this has to do with u-boot or with the format of the ELF file.

In the other hand, I have seen two things in the configuration of the bootloader that I would like to know if they must be fixed.

- When u-boot starts it shows that the system has 64MB of DRAM, but the OMAP-L138 SOM has 128MB. In the "da850_evm.h" file I have changed PHYS_SDRAM_1_SIZE from 0x04000000 to 0x08000000 and now u-boot shows 128MB. Is that correct.

- I think the bootarg "mem=34M" passed to the Linux kernel by default use only 34MB of RAM. Would not it be better to pass "mem=128M" to the Linux kernel?

Best regards.

[JohnW]

My guess - if you're running a Linux elf, doesn't the entry point default at 0x00000000?  I don't really know.  I haven't run bootelf.  What are you trying to do?

Sounds like we need to update u-boot to use the max memory on the SOM.

Regarding the MEM= argument, that does set the max memory that Linux can manage.  What you set it to is a matter of system design.   If you are using the DSP, it cannot be working in the same memory space as Linux.  So, you set the DSP to use a different region of memory.  I think by default in the OMAP-L138 it uses the top 16MB of the lower 64MB (this way the same config works with both 64MB and 128MB SOMs), but you can set it to use other memory regions.  In our Speedway series, we set it to use the upper 64MB of memory because we were allocating some big frame buffers.

Keep in mind that the MEM= argument sets the amount of memory that the Linux can manage/access.  There are other IPC mechanisms and memory allocators that TI provides (CMEM and DSPLINK) for working with shared memory and the DSP, but these are all using memory that is outside of the Linux-managed space.

Hope this helps.

[sergios_]

Hello John,

I was loading the ELF file in RAM in an address too low, so that when I used the bootelf command the executable binary image and the ELF file overlapped. Now I have download the ELF file using tftp to a higher RAM address and boot it using the bootelf command successfully.

Thanks for all. Best regards.