Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20644 Discussions

Cyclone V SoC Preloader will not run bare metal app

Altera_Forum
Honored Contributor II
6,423 Views

Hello all, 

 

I've been working on this problem for several days now. I've read every website/pdf I can find (e.g. these forums, rocketboards, altera pdfs, etc, etc, etc, etc) regarding bare metal applications on Cyclone V SoC and I still can't get this to work. I've gotten pretty far but I've basically run out of steam. I usually never post on forums unless I've tried every possible thing I can think of and have totally run out of ideas and places to search. I think I must just be missing something very simple. 

 

Here's what I've done so far (targetting DE10-Nano board): 

 

1) Created basic HPS design with UART and SDMMC peripherals enabled and DDR3 settings configured same as golden reference design that was provided with the board 

 

2) Built hardware design to .SOF without error and converted SOF to RBF so that it can be loaded by pre-loader 

 

3) Using the 'hps_isw_handoff' I created the spl_bsp with bsp-editor and configured to boot from SDMMC 

 

4) Compiled preloader using 'make' which generated preloader-mkpimage.bin without error 

 

5) Ran alt-boot-disk-util to update pre-loader image on special partition of SD card 

 

6) Created SD/MMC example C project in SoC EDS application (from https://www.altera.com/content/dam/altera-www/global/en_us/others/support/examples/soc/altera-socfpga-hardwarelib-sdmmc-cv-gnu.tar.gz

 

7) Compiled example C project to .AXF with no errors using baremetal GCC arm-altera-eabi- toolchain 

 

8) Copied AXF file to SD card FAT partition and inserted SD card into board 

 

9) Powered on board 

 

Pre-loader uboot output is as follows: 

U-Boot SPL 2013.01.01 (Sep 04 2017 - 20:01:43) BOARD : Altera SOCFPGA Cyclone V Board CLOCK: EOSC1 clock 25000 KHz CLOCK: EOSC2 clock 25000 KHz CLOCK: F2S_SDR_REF clock 0 KHz CLOCK: F2S_PER_REF clock 0 KHz CLOCK: MPU clock 800 MHz CLOCK: DDR clock 400 MHz CLOCK: UART clock 100000 KHz CLOCK: MMC clock 50000 KHz CLOCK: QSPI clock 3125 KHz RESET: COLD INFO : Watchdog enabled SDRAM: Initializing MMR registers SDRAM: Calibrating PHY SEQ.C: Preparing to start memory calibration SEQ.C: CALIBRATION PASSED SDRAM: 1024 MiB ALTERA DWMMC: 0 U-Boot 2017.03-rc2 (Mar 30 2017 - 19:07:16 -0700) CPU: Altera SoCFPGA Platform FPGA: Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0 BOOT: SD/MMC Internal Transceiver (3.0V) Watchdog enabled I2C: timeout in enabling I2C adapter timeout in enabling I2C adapter ready DRAM: 1 GiB MMC: dwmmc0@ff704000: 0 timeout in enabling I2C adapter timeout in enabling I2C adapter In: serial Out: serial Err: serial Model: Terasic DE10-Nano Net: No ethernet found. Hit any key to stop autoboot: 0 => run fpga_cfg reading de10-nano.rbf 1952756 bytes read in 192 ms (9.7 MiB/s) => load mmc 0:1 0x01000000 sdmmc_example.axf reading sdmmc_example.axf 669244 bytes read in 73 ms (8.7 MiB/s) => bootelf CACHE: Misaligned operation at range CACHE: Misaligned operation at range CACHE: Misaligned operation at range CACHE: Misaligned operation at range CACHE: Misaligned operation at range CACHE: Misaligned operation at range # # Starting application at 0x00100040 ... INFO: System Initialization.INFO: Setting up Global Timer.INFO: Setting up SDMMC.RESULT: Some failures detected. 

 

As you can see the pre-loader loads the FPGA design file. The configuration DONE light turns on so I know configuration is successful. 

 

However, the example application fails. Clearly there are some cache issues but I have no idea what they mean or why they are happening. But then the example application starts and just fails with no indication as to why. I inserted some printfs into the example code and it fails at the call to alt_sdmmc_card_identify(). 

 

I'm not sure if the 0x01000000 address that I'm loading to makes sense. The only reason that I'm using it is because that's the address that the 'bootelf' command tries to load from. 

 

It's obvious that the SD card peripheral is working since the pre-loader can read from it. I also tried changing the u-boot environment variables and writing them back to the SD card and that worked as well. So SD card read/write operation seems OK. 

 

It's also obvious that the DDR is working because the pre-loader can clearly write the ELF file to the DDR at address 0x01000000 and the HPS can obviously read from it since the application does in fact run (just not successfully). 

 

Can someone please help me figure this out? 

 

Regards 

 

P.S. I'm not interested in using the debugger to load the application. I need the fpga design and application to be loaded off of the SD card as I've shown. So please don't reply with "use the debugger and make a debug script" or similar. I need the board to boot and just start running without cables attached. 

 

UPDATE: I've also tried the GPIO example from the altera website (https://www.altera.com/content/dam/altera-www/global/en_us/others/support/examples/soc/altera-socfpga-hardwarelib-gpio-cv-gnu.tar.gz) and doesn't even successfully print the first printf statement. Instead it just prints a bunch of garbage: 

 

=> load mmc 0:1 0x01000000 gpio_example.axf reading gpio_example.axf 610864 bytes read in 64 ms (9.1 MiB/s) => bootelf CACHE: Misaligned operation at range CACHE: Misaligned operation at range CACHE: Misaligned operation at range CACHE: Misaligned operation at range CACHE: Misaligned operation at range CACHE: Misaligned operation at range # # Starting application at 0x00100040 ...-ÊÊêJåÍѵ%¹¥Ñ¥±¥é?½¹¹J9=éJ¹¥ÑA%=j½Õ±¹J9=éÑÑ¥¹ÕÁA%=¥¹ÑÉÉÕÁ?J9=??ÕÁ:A%=½Éb?J9=é?ÕÁA%=½ÉAÕÍ¡ ÕÑ?¹¹J9=?¥ÍÑ?¥¹ÑÉÉÕÁ?¢¹±É¹J9=é?ÍÍ"AM}A }UMI}ÁéBAM0? ±¥¹*¹J9=??ÍÍ!AM}A }UMI}ÅéB5b5E5??±±?¡Ñ¹J9=??ÍÍBAM}A }UMI}ÉêBAM"???±±b?J9=??ÍÍ!AM}A }UMI}ÍÒB5b)E5ÒÕ?½¹á¥Ñ¢µ½¹
0 Kudos
26 Replies
Altera_Forum
Honored Contributor II
3,087 Views

It's not that hard to create a debug configuration. Why are you so against testing it that way?

0 Kudos
Altera_Forum
Honored Contributor II
3,087 Views

If you think using the debugger will somehow get the SD card approach to work then I'm OK with trying it. My point is that if the design works with the debugger that's great but ultimately it doesn't end up helping me because I need it to work without the debugger. There are several forum posts for SoC issues where people suggest using the debugger, it works, and then no one bothers to help anymore even though that's not what the original poster requested help with. I want to avoid this. 

 

Additionally, the bare metal applications that I'm running are not mine. They are known working altera reference designs. So I'm not sure what I'd be debugging as far as the software is concerned...? I'm more apt to believe at this point that this is a process/flow issue (like I'm skipping a step or using the wrong file format or something) rather than an application bug. 

 

If you'd like to point to or provide some debug instructions I'll try it out and report results. I've never used the debugger before. Just keep in mind that I'm using the bare metal GCC arm-altera-eabi- toolchain and not the licensed ARM DS-5 tool-chain.
0 Kudos
Altera_Forum
Honored Contributor II
3,087 Views

jwdonal, 

 

have you considered using a simpler program instead? 

Alike "hello world" or toggling the LED on the DE0-10 nano connected to the HPS. 

Without the licensed DS-5, you will be limited to what U-BOOT offers: memory dumps. 

You should look at the memory map file from your compilation/link, check the generated code with objdump (the exception jump table is a good one) and then verify the code binary values are at the expected memory locations with UBOOT's md command. 

 

Regards
0 Kudos
Altera_Forum
Honored Contributor II
3,087 Views

Just wanted to give a last update to this thread. After several weeks of attempting to get this to work I was finally able to get bare metal apps working but not with u-boot. U-boot never worked for me. I think the worst part about this is getting the same bare metal app running on Xilinx Zynq devices is totally trivial compared to my experience with Altera. Same goes for Linux on Xilinx Zynq devices. With the Xilinx tools and chips everything "just works" as you'd expect - no fuss. Here are my final tallies for getting bare metal and linux apps to work on Xilinx Zynq and Altera Soc devices (having the same amount of prior technical experience using both vendors chips): 

 

- Xilinx Zynq Bare metal = 1 day 

- Xilinx Zynq Linux OS = 2 days 

- Altera SoC Bare metal = 3 weeks 

- Altera SoC Linux OS = 2 weeks 

 

I also find it pretty ridiculous that getting a full Ubuntu linux distribution working on an Altera SoC took _less_ time to get working than it did to get a bare metal app working. Absurd. 

 

The# 1 issue I ran into with the Altera SoC flow was the major lack of documentation and reference designs. Some of the reference designs worked but as soon as I tried to create my own design using the same steps nothing worked.
0 Kudos
Altera_Forum
Honored Contributor II
3,087 Views

Hi jwdonal & all, 

 

I'm struggling myself to have a small bare-metal demo loading from SD card, and I'm actually not interested in having uboot. The steps I followed are: 

1. Got the GHRD for my platform (DE0-Nano) 

2. Created a BSP using BSP editor. I'm booting from SD and enabled FAT support. 

3. Build preloader successfully 

4. Used alt-boot-disk-util to write pre-loader image to the relevant partition on the SD card 

5. I have a small "hello world" application that I was able to load via DS5. 

6. Using 'mkimage' tool I've created an *.img file and copied it to the FAT partition 

 

Unfortunately, the small app wouldn't load. I forgot mentioning that in the BSP editor I'v modified the FAT_LOAD_PAYLOAD_NAME to the *.img file. It seems like preloader loads the file but can't jump to it. I might be using mkimage in a wrong manner, I'm not sure. 

I see you are mentioning that you were able to load a bare-metal application without uboot, so I'd really appreciate if you can share your steps or at least point out what I was missing in mine. 

 

Thanks.
0 Kudos
Altera_Forum
Honored Contributor II
3,087 Views

Thanks for the information!! 

 

The missing part in my "puzzle" was the placement of the image in the memory layout. 

I'm using mkimage for generating the 'img' file, and since it adds 0x40 bytes of header it was important to update the linker where I'd like the actual code to begin. 

 

After aligning that, the preloader was launching my application. I didn't invest in trying to launch my application from uboot.
0 Kudos
Altera_Forum
Honored Contributor II
3,087 Views

Yes, I saw the same kind of 0x40 offset used in the linker file for the Unhosted sample, so I merged that into the SDMMC code sample, and it started working. I saw a similar solution posted here: 

https://forum.rocketboards.org/t/hwlib-example-design-is-not-running-on-my-custom-board/217/3
0 Kudos
Altera_Forum
Honored Contributor II
3,087 Views

Hello elizr and austin944, 

 

I'm beginner on this approach (bare metal in FPGA fabric) and I would like to ask if it's possible, if you can post the tutorial or article that explains how to create the SD card to boot a bare metal code from preloader because the documentation of terasic from DE10-Nano doesn't match this topics (bare metal).
0 Kudos
Altera_Forum
Honored Contributor II
3,087 Views

The following Wiki describes the different types of HPS booting for a Cyclone V system like the DE10-Nano: 

 

http://www.alterawiki.com/wiki/socbootfromfpga 

 

1) Boot from SD/MMC card, 

2) Boot from QSPI, 

3) Boot from NAND, 

4) RAM Boot - on Warm Reset only, 

5) Boot from FPGA, 

6) FPGA Fallback boot. 

 

I've only done# 1 so far, where the preloader and the baremetal application are loaded onto the SD card. Which one are you interested in? 

You mention "bare metal in FPGA fabric", so do you mean# 5 above?
0 Kudos
Altera_Forum
Honored Contributor II
3,087 Views

 

--- Quote Start ---  

The following Wiki describes the different types of HPS booting for a Cyclone V system like the DE10-Nano: 

 

http://www.alterawiki.com/wiki/socbootfromfpga 

 

1) Boot from SD/MMC card, 

2) Boot from QSPI, 

3) Boot from NAND, 

4) RAM Boot - on Warm Reset only, 

5) Boot from FPGA, 

6) FPGA Fallback boot. 

 

I've only done# 1 so far, where the preloader and the baremetal application are loaded onto the SD card. Which one are you interested in? 

You mention "bare metal in FPGA fabric", so do you mean# 5 above? 

--- Quote End ---  

 

 

Thanks for the quick reply Austin, sorry for the confusion but when I mentioned bare metal I mean to boot from SD/MMC card to program the FPGA with the .rfb or .sof file and then start the bare metal application for the ARM, also I don't know exactly who programs the FPGA itself but my idea is to load some hdl into FPGA and then start my application (c baremetal) that'll talk with the hdl. Reading the documents I think that the main idea is to use this flow: 

boot rom -> preloader -> bare metal (ARM)  

:)
0 Kudos
Altera_Forum
Honored Contributor II
3,087 Views

Hello Austin, 

 

I've been reading the boot types and I still didn't find a solution for bare-metal application. My goal is to load up a design into FPGA (with the .rbf file) and then load my binary bare-metal application for ARM-A9. Today what I could do is to generate the preloader (preloader-mkpimage.bin) and my FPGA raw files to program (.rbf) but I couldn't find some tutorial of how to generate the u-boot.scr and u-boot.script to program FPGA and load the binary. =/ 

Btw, if I understood right to loadup the design and boot some bare-metal app you need and SD/MMC with: 

 

Partitions: 

fat32: 

------ u-boot.img 

------ u-boot.scr 

------ baremetalapp.bin 

------ soc_design.rbf 

 

a2: 

------ preloader-mkpimage.bin 

 

Am I right about this?
0 Kudos
Altera_Forum
Honored Contributor II
3,087 Views

 

--- Quote Start ---  

Hello Austin, 

 

I've been reading the boot types and I still didn't find a solution for bare-metal application. My goal is to load up a design into FPGA (with the .rbf file) and then load my binary bare-metal application for ARM-A9. Today what I could do is to generate the preloader (preloader-mkpimage.bin) and my FPGA raw files to program (.rbf) but I couldn't find some tutorial of how to generate the u-boot.scr and u-boot.script to program FPGA and load the binary. =/ 

Btw, if I understood right to loadup the design and boot some bare-metal app you need and SD/MMC with: 

 

Partitions: 

fat32: 

------ u-boot.img 

------ u-boot.scr 

------ baremetalapp.bin 

------ soc_design.rbf 

 

a2: 

------ preloader-mkpimage.bin 

 

Am I right about this? 

--- Quote End ---  

 

 

I already can generate the binary bare metal with the mkimge header with the command: 

$(MKIMAGE) -A arm -T standalone -C none -a 0x100040 -e 0 -n "baremetal image" -d $(BIN) $(IMG) 

but when I try to run the u-boot.scr the output fails to run, my script is: 

u-boot.script: 

fatload mmc 0:1 $fpgadata soc_system.rbf; 

fpga load 0 $fpgadata $filesize; 

run bridge_enable_handoff; 

fatload mmc 0:1 0x00100040 hello-mkimage.bin;  

go 0x00100040; 

 

$(MKIMAGE) -A arm -T standalone -C none -a 0x100040 -e 0 -n "uboot script" -d u-boot.script u-boot.scr 

 

And the output is: 

U-Boot 2013.01.01 (Feb 14 2018 - 16:14:30) 

 

CPU : Altera SOCFPGA Platform 

BOARD : Altera SOCFPGA Cyclone V Board 

I2C: ready 

DRAM: 1 GiB 

MMC: ALTERA DWMMC: 0 

*** Warning - bad CRC, using default environment 

 

In: serial 

Out: serial 

Err: serial 

Skipped ethaddr assignment due to invalid EMAC address in EEPROM 

Net: mii0 

Warning: failed to set MAC address 

 

Hit any key to stop autoboot: 0 

reading u-boot.scr 

228 bytes read in 5 ms (43.9 KiB/s) 

# # Executing script at 02000000 

Bad image type 

reading zImage 

** Unable to read file zImage ** 

reading socfpga.dtb 

** Unable to read file socfpga.dtb ** 

Bad Linux ARM zImage magic!
0 Kudos
Altera_Forum
Honored Contributor II
3,087 Views

I'm just a beginner myself, so take my advice with a grain of salt, but the options to the mkimage command looks suspect to me: 

 

$(MKIMAGE) -A arm -T standalone -C none -a 0x100040 -e 0 -n "uboot script" -d u-boot.script u-boot.scr 

 

I think what you want is something that looks more like that seen in the following web page (URL split with * instead of / to get past spam filter): 

rocketboards . org * foswiki * Documentation * GSRD131ProgrammingFPGA 

 

Here they use: 

"$ ~/cv_soc_devkit_ghrd/software/spl_bsp/uboot-socfpga/tools/mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "My script" -d u-boot.txt u-boot.scr" 

 

 

There is another way to get the u-boot.scr script file to work, which allows you to bypass using the mkimage command. 

When you see this prompt: Hit any key to stop autoboot: 0 

Hit a key to stop the boot process. You will be at the bootloader prompt. 

Then just type in the commands from the u-boot.txt file, one line at a time. Once that works, then there is a way to 

save these commands in the environment so you don't have to re-type them each time the system boots.
0 Kudos
Altera_Forum
Honored Contributor II
3,087 Views

I found some documentation that explains how to use mkimage for creating the u-boot.scr file (URL has * instead of / to get past spam filter): 

 

www . denx.de * wiki * view * DULG * UBootScripts 

 

At the bootloader prompt, can you type "printenv" and attach the output as an attachment?
0 Kudos
Altera_Forum
Honored Contributor II
3,087 Views

Hi austin, hi aignacio 

I post in this thread since I think I'm stuck in a similar situation and I hope someone of you can help me. 

 

I have a cyclone V de0 nano soc board and I want to boot a bare metal application from SD card. 

This is what I could do so far: 

- I built a working baremetal application and I can debug via jtag 

- I created the u-boot.scr script file to load fpga configuration and baremetal application 

- I copied the .scr on SD card and it get executed, as I can see in the serial port output log 

- during the boot process, FPGA can successfullly configure from the .rbf file I copied in the FAT partition of SD card 

- when the script tries to load the application (fatload mmc 0:1 0x00100040 app_image.bin) I clearly get an error, since I still don't have the app_image.bin which is supposed to contain my application.  

The point is that I don't understand how to generate it from the .axf file I get from the build tools! 

 

I read this and other threads and I believe I simply need this .bin file on the SD card 

I used objcopy as someone suggested, but this creates a 4GB file! Moreover mkimage then tells me it can't read it. 

 

I'm missing some point?
0 Kudos
Altera_Forum
Honored Contributor II
3,087 Views

 

--- Quote Start ---  

Hi austin, hi aignacio 

I post in this thread since I think I'm stuck in a similar situation and I hope someone of you can help me. 

 

I have a cyclone V de0 nano soc board and I want to boot a bare metal application from SD card. 

This is what I could do so far: 

- I built a working baremetal application and I can debug via jtag 

- I created the u-boot.scr script file to load fpga configuration and baremetal application 

- I copied the .scr on SD card and it get executed, as I can see in the serial port output log 

- during the boot process, FPGA can successfullly configure from the .rbf file I copied in the FAT partition of SD card 

- when the script tries to load the application (fatload mmc 0:1 0x00100040 app_image.bin) I clearly get an error, since I still don't have the app_image.bin which is supposed to contain my application.  

The point is that I don't understand how to generate it from the .axf file I get from the build tools! 

 

I read this and other threads and I believe I simply need this .bin file on the SD card 

I used objcopy as someone suggested, but this creates a 4GB file! Moreover mkimage then tells me it can't read it. 

 

I'm missing some point? 

--- Quote End ---  

 

 

 

Hello Cris72, 

 

to generate the .bin file you'll need to use this command after generate your .axf: 

arm-altera-eabi-objcopy -o binary baremetal.axf baremetal.bin 

Also as I was stucked in this generation steps, I decided to make a big tutorial for my blog to explain all the process after understand the required files to generate a bootable SD card. As my post is not complete yet I'll paste here a preview that's only accessible through this link (https://blog.aignacio.com/p/b0ed896e-9982-4b40-a3e9-cc8cabea31ff/), try to read my tutorial and check if this could help you through the steps and if you find any error just reply. :)
0 Kudos
Altera_Forum
Honored Contributor II
3,087 Views

Hello ignacio 

Thank you very much for your kind answer. I don't have time now to read your tutorial, but at first glimpse it seems very interesting. I'll do it next monday. 

 

Regarding the arm-altera-eabi-objcopy command line, I understood this is what I'm supposed to use. But, as I wrote in my post, this generates the full 4GB addressable memory image, and the file is useless.  

I guess that this happens because my axf file contains both sections in the 0-0x100000 memory range (mainly sdram) and sections in the 0xFFFF0000-0xFFFFFFFF range (I think these are for SoC onchip ram and memory mapped registers, am I right?), then objcopy creates an image from the lowest address 0 to the highest 0xFFFFFFFF, although a miminal part is actually relevant.  

Infact if I exclude sdram or if I include a single memory section (objcopy options -j or -R) the bin file generates with the correct memory size. 

I also tried to generate separate files for each memory section and tried to manually load them with the 'fatload' command: using the debugger I can see the memory gets correctly loaded with the bin data, but I really don't know if I'm placing this section where they are supposed to be. Moreover I have no idea where my code must start from: I tried a go 0x00100040, but nothing seems to happen.
0 Kudos
Altera_Forum
Honored Contributor II
3,087 Views

Cris72, 

I think your observation about the onchip ram is correct. In my application, I only have symbols defined in the onchip ram at 0xffff0000 

and don't allocate any data or code in that space. That allocation is done in the linker script. I guess that's the reason why the .axf file 

and resulting .bin file don't contain data/code that needs to be initialized in that space. 

 

You can check for the condition you mention in the .axf file, with the following command: 

arm-altera-eabi-objdump -x <name of axf file> 

 

In my case, I get these sizes for the various sections in my .axf file. Note that the size is zero for the oc_ram sections

 

Sections: 

Idx Name size VMA LMA File off Algn 

0 .text 0001df74 00100040 00100040 00010040 2**6 

CONTENTS, ALLOC, LOAD, READONLY, CODE 

1 .eh_frame 00000004 0011dfb4 0011dfb4 0002dfb4 2**2 

CONTENTS, ALLOC, LOAD, READONLY, DATA 

2 .ARM.exidx 00000008 0011dfb8 0011dfb8 0002dfb8 2**2 

CONTENTS, ALLOC, LOAD, READONLY, DATA 

3 .rodata 00000f08 0011dfc0 0011dfc0 0002dfc0 2**3 

CONTENTS, ALLOC, LOAD, CODE 

4 .cs3.boot_rom 00000000 fffd0000 fffd0000 0002f9c0 2**3 

CONTENTS 

5 .cs3.boot_rom.bss 00000000 fffd0000 fffd0000 0002f9c0 2**0 

CONTENTS 

6 .cs3.oc_ram 00000000 ffff0000 ffff0000 0002f9c0 2**3 

CONTENTS 

7 .cs3.oc_ram.bss 00000000 ffff0000 ffff0000 0002f9c0 2**0 

CONTENTS 

....
0 Kudos
Altera_Forum
Honored Contributor II
3,087 Views

Thank you for your answer austin944.  

I followed your advice and I made a great step forward, although I'm still not able to boot the application. 

I changed the linker file and mapped all the oc_ram sections to sdram, i.e. at positive address. 

Now all sections in 0xffff0000 have zero size like in your example and infact I can now generate an image file with a reasonable size! 

 

I'm now stuck on another weird point.  

I created the following img file with mkimage an put it on sdcard.  

It gets loaded into sdram but, if I inspect memory after the fatload command, I see the data (which is correct) is misplaced.  

To me it seems an endianess problem, since I see the low and high words swapped. 

For example, at address 0x100000 I'm supposed to have 0xE59F F018, but I find 0xF018 E59F
0 Kudos
Altera_Forum
Honored Contributor II
2,783 Views

Here is something else I've discovered.  

 

Regarding the endiannes problem, the data is shown as misplaced only in the disassembly window of the usb-blaster debugger. 

The data appears to be ok in the memory window of the debugger or if I dump the memory with the md command from the serial port interface. 

Which is correct? 

 

The section gets loaded starting at memory address 0x100040, no matter the address I specify in linker or in mkimage. 

Instead, if I directly load the bin file generated by objcopy, without using mkimage, it loads correctly (i.e. isr vector table at 0x100000 and cs3_reset at 0x100040) 

What's the actual difference between objcopy and mkimage ouput? 

 

**** discard this part: this was my error; see my following post  

The last point is not completely true, because between interrupt vector and cs3_reset I always find a stray code 0xEA00024 which shifts all the remaining part to higher addresses. 

I mean: 

0x100000 : interrupt vector 

0x100040 : stray data 0xEA00024 ??? 

0x100044; cs3_reset + cs3_start_c code which is supposed to be @0x100040 

****  

 

 

I'm very puzzled of this. I hope someone can explain me
0 Kudos
Reply