[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Please help.. I wish to load .elf file directly for baremetal run..

From: Jakob Bohm
Subject: Re: Please help.. I wish to load .elf file directly for baremetal run..
Date: Thu, 18 Mar 2021 23:08:21 +0100
User-agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:4.8) Goanna/20210302 Interlink/52.9.7731

You have to think like a real bare-metal programmer.

First think of your computer as a real piece of hardware
made from real chips with real data sheets and real PCB
tracks connecting them.  This provides you with a set of
limitations and opportunities.

Write (or borrow) your own code to load your linker
sections at desired RAM addresses from the contents of
your Flash EEPROM chip, this could be a simple as doing
memcpy to specific RAM address ranges from specific ROM
address ranges, or it could be code that parses some data
structures in the ROM image to determine where to copy
stuff (Pro tip: Initialize your DRAM controller before
using the RAM for anything).

Then write (or borrow) a script or program to pack your
linker sections into the physical size of your EEPROM

Special Note: On the PC platform the ROM BIOS is the
only true bare metal program, and does a lot of initial
stuff before running the "almost bare metal" OS loader
from the main disk image.

On 2021-03-17 08:35, ckim@etri.re.kr wrote:

If I change the linker script so that the program loads and starts at RAM address, I can use -kernel test.elf and run the program.

But I’m still curious if I can load the program at 0x0 (ROM area) and use some data at 0x40000000 (RAM) like we can do in rtl simulation.


Chan Kim

*From:*ckim@etri.re.kr <ckim@etri.re.kr>
*Sent:* Wednesday, March 17, 2021 3:29 PM
*To:* 'qemu-discuss' <qemu-discuss@nongnu.org>
*Subject:* Please help.. I wish to load .elf file directly for baremetal run..

Hello all,

Using the help from this email list, I’m using command below for my baremetal program test on qemu. (-s -S for connecting with gdb) :

$aarch64-none-elf-objcopy -O binary test.elf test.bin

$cp test.bin pflash.img; truncate -s 67108864 pflash.img        //to cut it down to 64MB because the pflash size is 64MB)

$qemu-system-aarch64 -machine type=virt,gic-version=3,secure=true,virtualization=true -cpu cortex-a72 -nographic -smp 1 -m 2048 -drive if=pflash,file=pflash.img,format=raw,readonly=on -s -

The entry address is 0. The problem is this test.bin can become very big when I have some space between section.

For example, if I want to put some initialized data (that can be changed) in RAM at 0x40000000, this bin file becomes bigger than 1GB. (because it fills the in-between spaces in .bin file)

I tried just using -kernel test.elf but it errors in rom_check_and_register_reset() inside qemu_init.

And the arm64 virt machine places dtb in the first RAM area.

Isn’t there any option though which I can just load the .elf file (each section to its address) and run from the entry address?

and is it possible to disable dtb loading at the first RAM address?

Thank you for any help.

Chan Kim


Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

reply via email to

[Prev in Thread] Current Thread [Next in Thread]