Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
21 years ago

Still UBoot ing...

Well thanks to everyone one and all my UBoot seems to be up and running fine however I'm still having a little bit of grief getting the final bits working (think I'm gonna write an app note on this once I get it going). But I thought I'd start a new thread.

My system (lets says it's a Cyclone Dev kit board)

Has Flash at 0x00000000, EPCS at 0x00810800, and SDRAM at 0x01000000

Reset address in SOPC builder is set to EPCS and Exception Address is set to 0x01000020,

UBoot has been compiled to run at 0x01C000000 so its clear of the download area.

Now UBoot is stored in the EPCS and that correctly boots up an runs. I can download via dhcp application images

and successfully write them to the FLASH at location 0. The problem I have is in getting them to be in the correct format in oder to convince UBoot to execute them.

Let's say i have an example (small app) built without OS in the NIOS IDE, naturally it has defined reset address as0x00810800 and exception address is 0x01000020 in system.h

Now I take the elf and do a:

nios2-elf-objcopy -O binary sample.elf sample.bin

This generates from an approx 1000 byte image file (nios2-elf-size) an 8Meg binary file. (Why is this?).

I then gzip this up

gzip -c --best sample.bin > sample.gz

Size comes down to something reasonable.

finally I mkimage on this to create something reasonable for UBoot to load

mkimage -A nios2 -O linux -T kernel -C gzip -a 0x01000000-e 0x01000000 -n "MyAPP" -d sample.gz sample.img

Now do those addresses make sense for load and execute? Presumably the execute address ought to be set to _start or something similar? what about the load address?

Anyway after dhcp'ing this onto the target board (Normally I use 0x01100000 as the copy area), and then

flash it into 0x00000000. The program appears to be there (in zip form), however when I do a bootm, nothing much happens, it finds and says it is being uncompressed but locks at calling the kernel start address.

By commenting out the call to kernel start and returning to U-Boot, when i look at the area that should have had the program put into it nothing appears.

What is up here?

Regards,

11 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    The assembly code that generated the jump call was relative. The linker changed it because it was too far away. This means that if your memory layout changes, the process you used this time may not work in the future.

    Good to see you have it working though.

    regards,