thebuell
Posts: 33
Joined: Mon Sep 19, 2011 8:22 pm

screen04 from the bare metal programing articles

Sun Apr 21, 2013 8:01 pm

Mm, should the screen series of programs from the bare metal programming tutorials work on HDMI displays? I ask because mine doesn't show anything. Raspbian and RiscOS both work just fine.

socaslvr
Posts: 21
Joined: Sat Apr 13, 2013 10:34 pm

Re: screen04 from the bare metal programing articles

Mon Apr 22, 2013 1:17 am

Code: Select all

kernel_old=1
Add this line to your config.txt

thebuell
Posts: 33
Joined: Mon Sep 19, 2011 8:22 pm

Re: screen04 from the bare metal programing articles

Mon Apr 22, 2013 8:42 pm

Thanks, that worked. What must I do to ensure the HDMI output is initialised so that I don't need to specify kernel_old=1?

socaslvr
Posts: 21
Joined: Sat Apr 13, 2013 10:34 pm

Re: screen04 from the bare metal programing articles

Tue Apr 23, 2013 4:17 am

Code: Select all

MEMORY
{
    ram : ORIGIN = 0x8000, LENGTH = 0x10000
}
I believe this has to do where the kernel is loaded in memory. Try adding that to your linker script, I believe this should place it at 0x8000 and you won't need to add that line to the config file, I may be wrong.

thebuell
Posts: 33
Joined: Mon Sep 19, 2011 8:22 pm

Re: screen04 from the bare metal programing articles

Tue Apr 23, 2013 6:14 pm

socaslvr wrote:

Code: Select all

MEMORY
{
    ram : ORIGIN = 0x8000, LENGTH = 0x10000
}
I believe this has to do where the kernel is loaded in memory. Try adding that to your linker script, I believe this should place it at 0x8000 and you won't need to add that line to the config file, I may be wrong.
Hmm, my kernel.ld is as follows:

Code: Select all

SECTIONS {

	.init 0x0000 : {
		*(.init)
	}

	.text 0x8000 : {
		*(.text)
	}

	.data : {
		*(.data)
	}

	/DISCARD/ : {
		*(*)
	}
}
Where would your bit go?

User avatar
rpdom
Posts: 14970
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: screen04 from the bare metal programing articles

Tue Apr 23, 2013 7:05 pm

This version of kernel.ld seems to work well for all my code so far :)

Code: Select all

/******************************************************************************
*	kernel.ld
*	 by Alex Chadwick
*
*	A linker script for generation of raspberry pi kernel images.
******************************************************************************/

SECTIONS {
	/*
	* First and formost we need the .init section, containing the IVT.
	*/
	.init 0x8000 : {
		*(.init)
	}
	
	/* 
	* We allow room for the ATAGs and the stack and then start our code at
	* 0x9000.
	*/
	.text 0x9000 : {
		*(.text)
	}
	
	/* 
	* Next we put the data.
	*/
	.data : {
		*(.data)
	}

	/*
	* Finally comes everything else. A fun trick here is to put all other 
	* sections into this section, which will be discarded by default.
	*/
	/DISCARD/ : {
		*(*)
	}
}

socaslvr
Posts: 21
Joined: Sat Apr 13, 2013 10:34 pm

Re: screen04 from the bare metal programing articles

Tue Apr 23, 2013 7:34 pm

thebuell wrote:Where would your bit go?
This should work, I believe this is from dwelch67's github.

Code: Select all

MEMORY
{
    ram : ORIGIN = 0x8000, LENGTH = 0x10000
}

SECTIONS
{
    .init : { *(.init*) } > ram
    .text : { *(.text*) } > ram
    .bss : { *(.bss*) } > ram
    .rodata : { *(.rodata*) } > ram
    .data : { *(.data*) } > ram
}
You can check your list file to see if code is placed at 0x8000.

Code: Select all

arm-none-eabi-objdump -D main.elf > main.list

thebuell
Posts: 33
Joined: Mon Sep 19, 2011 8:22 pm

Re: screen04 from the bare metal programing articles

Tue Apr 23, 2013 8:52 pm

socaslvr wrote:

Code: Select all

MEMORY
{
    ram : ORIGIN = 0x8000, LENGTH = 0x10000
}

SECTIONS
{
    .init : { *(.init*) } > ram
    .text : { *(.text*) } > ram
    .bss : { *(.bss*) } > ram
    .rodata : { *(.rodata*) } > ram
    .data : { *(.data*) } > ram
}
Brilliant, this one worked perfectly for me. thanks. The other one didn't work.

dwelch67
Posts: 955
Joined: Sat May 26, 2012 5:32 pm

Re: screen04 from the bare metal programing articles

Tue Apr 23, 2013 9:43 pm

Linux is the primary use case for the raspberry pi. They used to load kernel.img to address 0x0000 with a bunch of padding up front I assume for vectors and atags and such. Now the default (no config.txt) is to load kernel.img to 0x8000 and then the gpu does some writes to the 0x0000 - 0x7FFF space to add atags and at least a reset vector to branch to 0x8000.

The folks in this forum are split between use 0x8000 and live with the baggage that comes with it or use 0x0000 and live with the baggage that comes with it...I am not sure, but I believe we are beyond the point where the individual github files were one style (0x8000) and the pre-built sd card images were the other/older (0x0000), but I dont know for sure as I dont use the sd card images at all I only grab the few bootloader files from their github page.

David

Return to “Bare metal, Assembly language”