Help booting bare-metal

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Help booting bare-metal

Jump to solution
1,951 Views
failsafe_device
Contributor I

Hey everyone,

I recently bought an i.mx233 based board to mess around with and give me some more power than the AVR uC's I've been doing abit with lately. However I'm having trouble getting my code to run on the board (not really interested at putting an OS on it at this stage) and there doesn't seem to be much information floating around the web on how to do it either (one thing I miss about the AVR's).

As far as I can tell, once I have my compiled .elf file from my source code, which just attempts to turn on an GPIO pin on the board as output, I need to run elftosb (provided by freescale) to turn it into a safeboot file which I do using the following command:

elftosb -z -c make_boot.db -o boot.sb boot.elf

where my make_boot.db file is

// Define one input file that will be the first file listed
// on the command line. The file can be either an ELF file
// or an S-record file.

sources {

inputFile = extern(0);

}

// create a section
section (0) {

load inputFile; // load all sections
call inputFile; // jump to entry point

}

straight from the elftosb manual because it seems to be all I need

Once I have the safeboot file I need to get it onto a bootable uSD card which I do using the CFImager program (provided by freescale) and the command

CFImager -f boot.sb -d D

where D is the drive my uSD card is mounted.

I never get any errors but when I put it into my board no matter what state I set the GPIO pin to, nothing changes

Any Ideas?

Failsafe_Device

Labels (1)
Tags (3)
0 Kudos
1 Solution
1,404 Views
VladanJovanovic
NXP Employee
NXP Employee

Check imx-bootlets in Linux BSP (./ltib -m prep -p imx-bootlets #will be unpacked to <ltib>/rpm/BUILD/imx-bootlets...). Power_prep is bare metal code executed immediately after power-on and your code should probably achieve something similar. You can modify Makefile to suite your needs.

View solution in original post

0 Kudos
10 Replies
1,404 Views
Yuri
NXP Employee
NXP Employee

1.
As I expect the example boot.sb is intended to run in embedded memory (OCRAM) of the i.MX23.
Is boot.elf built (linked) correctly for the OCRAM ?

2.

The default SDK configuration for MMC/SD boots expects a FAT in partition 1,

the boot stream in partition 2, and the file system in partition 3.

So, SD card preparation may be as following :

dd if=/dev/zero of=mmc_boot_partition.raw bs=512 count=4

dd if=./boot.sb of=mmc_boot_partition.raw ibs=512 seek=4 conv=sync,notrunc

dd if=./mmc_boot_partition.raw of=/dev/sd[x]2

3.
Also USB loader may be applied :

sb_loader.exe /f boot.sb

1,404 Views
failsafe_device
Contributor I

Thanks for all the info. I'm not to sure if my .elf is linked correctly as I've been piecing things together for many different sources on the internet as I haven't been able to find much information. Are you able to point me to where you found all the information above?


In case it helps, here is the source and linker file I am using


- source file


.section .init

.globl _start

_start:

// Write to HW_PINCTRL_CTRL for standard GPIO pin operation

ldr r0,=0x80018000 // HW_PINCTRL_CTRL addr

mov r1,#0 // 0x00000000 standard GPIO operation

str r1,[r0] // store the value of r1 into the addr in r0

// Write to HW_PINCTRL_DOUT2, to set Pin1 to high (0x00000002)

ldr r0,=0x80018520       // HW_PINCTRL_DOUT2 add

mov r1,#2                     // 0x00000002 Pin1 High (Pin0 first pin)

str r1,[r0]                      // store the value of r1 into the addr in r0

// Write to HW_PINCTRL_DOE2, to finally enable output on Pin1 (0x00000002)

// Correct value already in r1, no need to reassign into

ldr r0,=0x80018720        // HW_PINCTRL_DOE1 addr

str r1,[r0]                      // store the value of r1 into the addr in r0

// DO NOTHING (LOOP)

loop$:                          // convention: $ for label if code not relevant to other sections

b loop$                        // branch to label loop$

- linker script


SECTIONS {

     .init 0x0000 : {

          *(.init)

     }

     .text 0x8000 : {

          *(.text)

     }

     .data : {

          *(.data)

     }

     /DISCARD/ : {

          *(*)

     }

}

I have a feeling the linker script is wrong, but I have no way of knowing.

Cheers.

0 Kudos
1,405 Views
VladanJovanovic
NXP Employee
NXP Employee

Check imx-bootlets in Linux BSP (./ltib -m prep -p imx-bootlets #will be unpacked to <ltib>/rpm/BUILD/imx-bootlets...). Power_prep is bare metal code executed immediately after power-on and your code should probably achieve something similar. You can modify Makefile to suite your needs.

0 Kudos
1,404 Views
failsafe_device
Contributor I

Thanks I'll have a look at that and see how i go.

cheers.

0 Kudos
1,404 Views
YixingKong
Senior Contributor IV

Mathew, if Vladan's answer helps you, please click Correct Answer, so that we can close the DI.

Thanks,

Yixing

0 Kudos
1,404 Views
failsafe_device
Contributor I

Hi, I've been really busy with work lately and I haven't had time to try anything or look up the imx-bootlets yet, but i have a feeling it should help, so I'll mark it as answered and then comment when I have had a chance to try.

0 Kudos
1,404 Views
fabio_estevam
NXP Employee
NXP Employee

What about running U-boot in your board?

0 Kudos
1,404 Views
failsafe_device
Contributor I

I was really trying to keep it simple in the sense that all I'm trying to do is start up the board and turn a GPIO pin on or off. I was thinking that a bootloader was kind of unnecessary. Thanks for the suggestion.

0 Kudos
1,404 Views
JackyAtFreescal
Senior Contributor II

Did you set the MUX properly?

0 Kudos
1,404 Views
failsafe_device
Contributor I

The board has been set to boot from MMC/SDCARD yes. This was set by the manufacturer and I have verified that it and my sdcard works by booting a linux image from it. Thanks for the reply by the way :smileyhappy:

0 Kudos