Bare Metal Assembly


31 posts   Page 1 of 2   1, 2
by shelluser » Tue May 22, 2012 9:47 am
Hi everyone,

My raspi should be arriving any day now and I wanted to get some info about programming the pi without an OS. I want to try out some stress tests which I've used before. They are written in C/Assembly and compiled using the ARM toolchain.

From what I understand, you need to place the code on the sdcard with a .img extension.

Is this just directly compiled code with a renamed extension or do you need to use some tool to convert it?

I've programmed other ARM chips before using a serial programmer but haven't got my head around the bootloader on the pi yet. I understand the GPU bootstraps the ARM but not sure how.

Has anyone managed to run code directly yet (without an OS on top)

Cheers,
shelluser
Posts: 2
Joined: Tue May 22, 2012 9:39 am
by DexOS » Tue May 22, 2012 1:12 pm
There not much info about the R-PI, but from the bit there is to boot a very basic OS.
You need a org 0x0000000 and a jmp to your start code.
That is it, remember it needs to be compiled as a flat binary (you will need to find out how to do that yourself, for your compiler)
But that it.
That will boot on the R-PI as kernel.img

But i would add one or two other things, i would set a stack up and jmp to 0x8000 in your code, you can also add the normal Arm interrupt vector under the first jump (first jump should = reset) and just point them to the same loop
eg:
JustLoop:
b JustLoop

Thats a basic R-IP boot layout.
Batteries not included, Some assembly required.
User avatar
Posts: 866
Joined: Wed May 16, 2012 6:32 pm
by cheery » Tue May 22, 2012 2:15 pm
The kernel.img is just a flat binary which gets loaded into address space starting from 0x00000000.

The first 0x20 bytes in that binary is an interrupt vector table. A trivial do-nothing program might look something like:
Code: Select all
.code 32
.org 0
    ldr pc, =reset
    nop ; undefined instruction
    nop ; software interrupt
    nop ; prefetch abort
    nop ; data abort
    nop ; ?
    nop ; IRQ
    nop ; FIQ

reset:
    b reset
User avatar
Posts: 219
Joined: Wed Jan 25, 2012 9:39 pm
by tufty » Tue May 22, 2012 2:55 pm
DexOS wrote:There not much info about the R-PI

There is, in fact, a large amount of information about the Pi. More than enough to write your own OS or run applications "on the bare metal". Just because you haven't managed to find out how to do it doesn't mean that the information doesn't exist.
DexOS wrote:jmp to 0x8000 in your code

Why? Do you have something against using the first 32K of memory?
shelluser wrote:I've programmed other ARM chips before using a serial programmer but haven't got my head around the bootloader on the pi yet. I understand the GPU bootstraps the ARM but not sure how.

As cheery pointed out, the bootloader simply grabs a flat image and dumps it into memory starting at 0x0, then trips the reset.

When you come in, basic muxing has already been done, the system clock is ticking (I believe) at 700MHz, you're in SVC mode (as usual) and you don't have any stacks set up. The MMU (as you see it from ARM space, there's actually a second one that does a GPU memory -> ARM memory mapping, but you mainly don't need to know about that) is not set up, so your memory space is flat from 0x0 to the top of RAM at 0x10000000, then the peripherals are mapped in starting at 0x20000000.

The GPU-ARM memory split gives you the top of usable RAM, but to use that you need to have implemented the GPU message passing interface (not too arduous) - viewtopic.php?f=31&t=6236 explains a good deal about this. Or you could just assume a particular boot configuration :)

The UART is an pl011, there's an sp084 timer as well as the system timer, and a whole load of other gubbins. Most of it is at least hinted at in the peripherals datasheet.

Simon
Posts: 1373
Joined: Sun Sep 11, 2011 2:32 pm
by shelluser » Tue May 22, 2012 6:28 pm
Thanks for the informative replies. I've written a basic OS with some simple memory management before so I get the idea.

I plan on releasing some of the tests and tools on github once I have some time on my hands. What compiler/assemblers are people using?

I only ask as I have the full ARM dev tools at my disposal and I'd find it pretty pointless releasing software if you need a license just to compile it. I'm not familiar with the open source tools out there.

Cheers,
shelluser
Posts: 2
Joined: Tue May 22, 2012 9:39 am
by Dave_G_2 » Tue May 22, 2012 6:45 pm
tufty wrote:[....]so your memory space is flat from 0x0 to the top of RAM at 0x10000000, then the peripherals are mapped in starting at 0x20000000 [....]


What is between 0x10000000 and 0x20000000 ?
Last edited by Dave_G_2 on Tue May 22, 2012 6:55 pm, edited 1 time in total.
User avatar
Posts: 196
Joined: Sat Apr 14, 2012 7:04 pm
by DexOS » Tue May 22, 2012 6:46 pm
tufty wrote:
DexOS wrote:There not much info about the R-PI

There is, in fact, a large amount of information about the Pi. More than enough to write your own OS or run applications "on the bare metal". Just because you haven't managed to find out how to do it doesn't mean that the information doesn't exist.
DexOS wrote:jmp to 0x8000 in your code

Why? Do you have something against using the first 32K of memory?

1.THE INFO available is from hacking the linux kernel, not from info from doc's
Just like the stuff you posted above, thats info come from hacking the linux kernel, that then posted around as doc, but its not.
Here's a example of where that comes from
/*
* ************************************************************************ *
* **** BCM2835 Specific Stuff **** *
* ************************************************************************ *
* This is where things get interesting (and specific to the BCM2835).
* Most of this was worked out by reading the Linux source code (mostly
* drivers/video/bcm2708_fb.c and arch/arm/mach-bcm2708/) and experimentation.
*
*
* **** Basic procedure to get stuff on screen ****
* The basic procedure to get a frame buffer is:
* 1) Set up a structure with the frame buffer specification (resolution, etc)
* 2) Tell the GPU about this structure by writing to the mailbox
* 3) Wait by reading from the mailbox for the GPU to modify this structure
* 4) Write to the frame buffer at the pointer we got in stage 3
* Only step 4 is required for subsequent writes to the frame buffer. Currently,
* I do not know how to enable the HDMI output, so this will always operate the
* composite, and not the HDMI.
*
*
* **** Mailbox operations ****
* Read/write operatitons on the mailbox consist of transfering data via a
* 32 bit register. 28 bits of this 32 bit register are the data to be sent
* to the receiver, while the lower 4 bits specify the channel (channel 1 is
* the frame buffer, but there are others).
*
* To send data via the mailbox:
* 1) Wait for space in the mailbox
* 2) Write ((data << 4) || channel) to the write register TODO: Make implementation match
*
* To receive data via the mailbox:
* 1) Wait for the mailbox to be non-empty
* 2) Execute a memory barrier
* 3) Read from the read register
* 4) Check the lowest 4 bits of the read value for the correct channel
* 5) If the channel is not the one we wish to read from (i.e: 1), go to step 1
* 6) Return the read value >> 4 TODO: Make implementation match
* Note: This will not work if we're interested in reading from more than one
* channel as it does not handle the reception of other channels' data
*
*
* **** Memory mapped registers ****
* The bus address for the mailbox memory mapped registers is 0x7E00B880.
* This corresponds to an ARM physical address of 0x2000B880 (the address we
* use from the ARM processor, and hence here). We use three registers from
* the mail box:
* - The read register for mailbox 0 at offset 0x00
* - The status register for mailbox 0 at offset 0x1C
* - The write register for mailbox 0 at offset 0x20 (this is actually the read
* register for mailbox 1).
*
*
* **** Notes ****
* - The address of the frame buffer must be at least a multiple of 16 (in
* order to be accurately transmitted in the 28 bits available in the
* mailbox)
* - The 32 bit value we actually send over the mailbox (including the channel)
* is (ADDRESS | 1) where ADDRESS is the address of the structure. This is
* equivalent to sending as the data (ADDRESS >> 4) (remember we do data << 4)
* - This works if we set vwidth = width, vheight = height, x = 0, y = 0.
* - I haven't managaged to make anything but 24 bit depth work, however the
* Linux source seems to use 16 bit?!
* - Sometimes the procedure described to get stuff on the screen doesn't
* work first time. I've hacked around this by repeating until it does work.
* - The two conditions for successfully acquiring a frame buffer are:
* - The data read from the mailbox (with the 4 least significant bits set
* to zero) is 0 (or 1 including the channel)
* - The pointer in the structure is non-zero after the mailbox read
* - Once we have the frame buffer, we can just write to it. The pixels (in
* 24 bit mode) are RGB ordered by y then x coordinate. The address of a
* subpixel is given by: y * pitch + x * 3 + rgb_channel, where rgb_channel
* is 0 for red, 1 for green, and 2 for blue.
*/

#define MAIL_BASE 0xB880 /* This is the base address for the mailbox registers
(actually, there's more than one mailbox, but this is the one we care about) */

/* Registers from mailbox 0 that we use */
#define MAIL_READ 0x00 /* We read from this register */
#define MAIL_WRITE 0x20 /* This is where we write to; it is actually the read/write of the other mailbox */
#define MAIL_STATUS 0x18 /* Status register for this mailbox */
//#define MAIL_CONFIG 0x1C - we don't actually use this, but it exists

//This bit is set in the status register if there is no space to write into the mailbox
#define MAIL_FULL 0x80000000
//This bit is set if there is nothing to read from the mailbox
#define MAIL_EMPTY 0x40000000

#define MAIL_FB 1 /* The frame buffer uses channel 1 */

struct Bcm2835FrameBuffer
{
uint32_t width; //Width of the frame buffer (pixels)
uint32_t height; //Height of the frame buffer
uint32_t vwidth; //Simplest thing to do is to set vwidth = width
uint32_t vheight; //Simplest thing to do is to set vheight = height
uint32_t pitch; //GPU fills this in; set to zero
uint32_t depth; //Bits per pixel; set to 24
uint32_t x; //Offset in x direction. Simplest thing to do is set to zero
uint32_t y; //Offset in y direction. Simplest thing to do is set to zero
uint32_t pointer; //GPU fills this in to be a pointer to the frame buffer
//I find this is usually (always?) 0x4F...TODO: Finish
uint32_t size; //GPU fills this in //TODO: Finish
};

static uint32_t mbox_read()
{
uint32_t r = 0;
do {
while (ReadMmReg32(MAIL_BASE, MAIL_STATUS) & MAIL_EMPTY);//wait for data
r = ReadMmReg32(MAIL_BASE, MAIL_READ); //Read the data
} while ((r & 0xF) != MAIL_FB); //Loop until we received something from the
//frame buffer channel
return r & 0xFFFFFFF0;
}

static void mbox_write(uint32_t v)
{
while (ReadMmReg32(MAIL_BASE, MAIL_STATUS) & MAIL_FULL); //wait for space
//Write the value to the frame buffer channel
WriteMmReg32(MAIL_BASE, MAIL_WRITE, MAIL_FB | (v & 0xFFFFFFF0));
}

static int TryInitFb()
{
//Some (or even all?) of these memory barriers can probably be omitted safely
MemoryBarrier();

//We need to put the frame buffer structure somewhere with the lower 4 bits zero.
volatile struct Bcm2835FrameBuffer *fb = (volatile struct Bcm2835FrameBuffer *)(1 << 22);
//See the comments for Bcm2835FrameBuffer
fb->width = 640;
fb->height = 480;
fb->vwidth = fb->width;
fb->vheight = fb->height;
fb->pitch = 0;
fb->depth = 24;
fb->x = 0;
fb->y = 0;
fb->pointer = 0;
fb->size = 0;

MemoryBarrier();
mbox_write(ArmToVc((void *)fb)); //Tell the GPU the address of the structure
//memory barrier is in the register read/write functions
MemoryBarrier(); //also an explicit one we probably don't need
uint32_t r = mbox_read(); //Wait for the GPU to respond, and get its response
MemoryBarrier();

if (r){ //If r != 0, some kind of error occured
WriteGpio(17);
return -1;
}

if (!fb->pointer){ //if the frame buffer pointer is zero, an error occured
WriteGpio(18);
return -2;
}

//Write a pattern for us to see this is working
MemoryBarrier();
volatile unsigned char *fbmem = (volatile unsigned char *)fb->pointer;
for (unsigned int i = 0; i < 800*200; i++){
switch(i % 3){
case 0: fbmem[i] = 63; break;
case 1: fbmem[i] = 127; break;
case 2: fbmem[i] = 255; break;
}
}
MemoryBarrier();

//Set up our frame buffer information
fbinfo.width = fb->width;
fbinfo.height = fb->height;
fbinfo.pitch = fb->pitch;
fbinfo.pointer = fbmem;

fbinfo.cb = (struct FrameBufferCharacter *)(1 << 23);
fbinfo.line_pos = 0;
fbinfo.charpix = (unsigned char *)0x10000; //We put the character map here
//For some reason, this does not work if we include a C file
//representation (that afaik is correct) - the character map ends up
//slightly jumbled as if it's being read at an offset

fbinfo.xoffs = 0; //It works in the x direction nicely (no overscanning)
fbinfo.yoffs = CHAR_HEIGHT; //cope with overscanning by adding 1 char border
fbinfo.cbwidth = fb->width / CHAR_WIDTH;
fbinfo.cbheight = (fb->height / CHAR_HEIGHT) - 2; //add 1 char border at the top and bottom

return 0;
}

void InitFb()
{
while (TryInitFb()); //Keep trying to make the frame buffer until it works
ClearScreen();
UpdateFb();
}

So yes i have loads of info on the R-PI, but its not from any doc's.
So do not tell me about getting info, as it could be all wrong.
Reverse engineering ( for want of a better word) is not DOCUMENT'S
2.As for the 0x8000, it should be obvious, the start vector is just a temp structure, that will need over writing before you can enable and use int's etc.
This leave room for that.
Also take a look at the offset of every ARM linux's
Batteries not included, Some assembly required.
User avatar
Posts: 866
Joined: Wed May 16, 2012 6:32 pm
by tufty » Tue May 22, 2012 7:43 pm
shelluser wrote:What compiler/assemblers are people using?

Personally, I'm using the GNU binutils (assembler, linker and assorted tools) and the LLVM clang compiler compiled for arm-none-eabi-. The syntax of the GNU assembler is a bit funky, but once you get used to it it's OK. For C, I've found that clang produces tighter code than gcc (which is pretty much universally reviled on ARM, although it's getting better), but it's still not as good as the ARM compiler. On the other hand, for the money you pay, you can't beat it :)

Docs on the GNU assembler here : http://sourceware.org/binutils/docs/as/
Dave_G_2 wrote:What is between 0x10000000 and 0x20000000 ?

Until the Pi grows more memory, Prefetch or Data Aborts, I would imagine. There's nothing mapped there by the GPU's MMU.
DexOS wrote:As for the 0x8000, it should be obvious, the start vector is just a temp structure, that will need over writing before you can enable and use int's etc.
This leave room for that.

Ohhhhhh-kay.

On the Pi, the vector table lives in RAM, not ROM like it might be on a "standard" microcontroller setup. There's absolutely no need to go through the whole "remapping" strategy that you might need to do on other platforms. As such, changing the (for example) IRQ vector is a simple case of disabling interrupts, write barrier, injecting your new interrupt handler, write barrier, turn on interrupts again. And even that is largely unnecessary, as, when you come in from a reset, interrupts are disabled - there's nothing stopping you from having the interrupt handlers already mapped in your kernel image.

In any case, the vector table uses 32 *bytes*, not 32 kilobytes. "Leaving room" isn't necessary.
DexOS wrote:Also take a look at the offset of every ARM linux's

There's a reason that the ARM Linux kernel jumps to 0x8000, but it doesn't apply if you're not using Linux.

Nice bit of reversing from the Linux source, though. I think there's an IRQ-based approach to doing the mailbox stuff that could be used, but I'm not sure if it's worth the effort TBH (especially if you're using it in early boot to size memory).

Simon
Posts: 1373
Joined: Sun Sep 11, 2011 2:32 pm
by DexOS » Tue May 22, 2012 8:17 pm
That info is not written by me, its just off the net, but I posted it has a example of what R-PI OS Dev teams need to do to get any clear info.
This is from the build.sh

cat first32k.bin kernel.img chars_pixels.bin > kernel.img.tmp
mv kernel.img.tmp kernel.img

Can you see what is put at the start of kernel.img :shock:
Even though its not linux, it still put a 32k buffer.
I am not 100% why its there, but the above example of FB did not work right until they started kernel at that offset.
For all we know, the binary blob could add something there, i just not sure.
Batteries not included, Some assembly required.
User avatar
Posts: 866
Joined: Wed May 16, 2012 6:32 pm
by Dave_G_2 » Tue May 22, 2012 8:40 pm
Since I'm not very familiar with ARM and the Pi, I'm a bit confused as regards the first 32K buffer
and the frame buffer.
As I read the code posted by DexOS above, to set up a frame buffer we must first create a structure
(10 words, 40 bytes long) and fill it with things like resolution, bit depth etc which must be at an address which is a multiple of 16 then tell the GPU where this structure is via the "mailbox" registers.
The GPU then modifies the second last word with a pointer to the frame buffer which the code above
states that it's almost always 0x4F.
If we make the resolution (as per above) 640X480X24 bit, then the fb would be 0xE1000 (921600) bytes
long and since it starts at 0x4F it would run to 0xE104F and completely over-writing the initial 32K buffer.

Also since our code starts at 0x0 + 0x20 bytes for the vector table + 0x28 bytes for the fb structure,
we would need a jump after that to somewhere after 0xE104F for the rest of our code.
Is this correct or am I missing something?
User avatar
Posts: 196
Joined: Sat Apr 14, 2012 7:04 pm
by DexOS » Thu May 31, 2012 3:00 pm
tufty wrote:In any case, the vector table uses 32 *bytes*, not 32 kilobytes. "Leaving room" isn't necessary.

I found the answer to starting at 0x8000 ?, and I was right you was wrong.
Heres why:
Because of "ATAGS" what are they ?, see here:

Its the list of parameters passed from the bootloader to the kernel.
These atag_list is a predefined structure which a bootloader can fill
and place at a location in RAM, whose address is passed to kernel
startup as a parameter. Typical things that can be passed are MAC
address of the box, initrd info etc.,

Now if you look at the config.txt, it has a setting, see here:
http://elinux.org/RPi_config.txt
disable_commandline_tags
This is not disabled by default, so it will write stuff like mac address to
(memory from 0x100) before launching kernel.
Can you not see a problem if you have code there ?.
Now can you see why we need to jump to 0x8000 ?
Batteries not included, Some assembly required.
User avatar
Posts: 866
Joined: Wed May 16, 2012 6:32 pm
by tufty » Thu May 31, 2012 4:35 pm
DexOS wrote:
tufty wrote:In any case, the vector table uses 32 *bytes*, not 32 kilobytes. "Leaving room" isn't necessary.

I found the answer to starting at 0x8000 ?, and I was right you was wrong.

Yeah, yeah. Nyer Nyer Nyer. etc.

I know all about atags, by the way, and the disable_commandline_tags thing isn't exactly hidden, is it? I refer you to my message of the 22nd, in which I wrote:
tufty wrote:There's a reason that the ARM Linux kernel jumps to 0x8000, but it doesn't apply if you're not using Linux.

Nice to see you managed to get something up and running (and with graphics, too). That's cool.

Simon
Posts: 1373
Joined: Sun Sep 11, 2011 2:32 pm
by DexOS » Thu May 31, 2012 5:45 pm
tufty wrote:Nice to see you managed to get something up and running (and with graphics, too). That's cool.

Simon

Thanks tufty, very nice of you to say that.
Batteries not included, Some assembly required.
User avatar
Posts: 866
Joined: Wed May 16, 2012 6:32 pm
by radford64 » Sat Jun 02, 2012 2:56 pm
You're right about the lack of proper documentation. :( There are lots of snippets of information floating about, but we could really do with a proper hardcore development wiki where it could all be gathered into one place. After all, the book that changed my life as a kid was The Advanced User Guide for the BBC Micro; it was like being given a box containing all the secrets of the universe! :D

Anyway, just wanted to point out that basic information about the memory map can be found in here:

And I might as well add that the exact variant of the cpu is an ARM1176JZF-S (Broadcom's website claims it's an ARM1176JZF, but everyone else says ARM1176JZF-S), which makes it an ARMv6 with VFP11/VFPv2. Datasheets at:

as usual. (Scroll to the bottom of each page for a pdf version.)
Posts: 2
Joined: Wed Mar 07, 2012 5:17 pm
by jamesh » Sat Jun 02, 2012 3:20 pm
radford64 wrote:You're right about the lack of proper documentation. :( There are lots of snippets of information floating about, but we could really do with a proper hardcore development wiki where it could all be gathered into one place. After all, the book that changed my life as a kid was The Advanced User Guide for the BBC Micro; it was like being given a box containing all the secrets of the universe! :D

Anyway, just wanted to point out that basic information about the memory map can be found in here:

And I might as well add that the exact variant of the cpu is an ARM1176JZF-S (Broadcom's website claims it's an ARM1176JZF, but everyone else says ARM1176JZF-S), which makes it an ARMv6 with VFP11/VFPv2. Datasheets at:

as usual. (Scroll to the bottom of each page for a pdf version.)


The thing about Wiki's is you can do them yourself - so please feel free to add the sections you want! It's a good idea!
Volunteer at the Raspberry Pi Foundation, helper at Picademy September and October 2014.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 12160
Joined: Sat Jul 30, 2011 7:41 pm
by DavidS » Mon Jun 04, 2012 4:10 pm
Many thanks the information posted in this thread has simplified the work of Operating System Development (at least for me [hopefully for others as well]).

It would be nice to get together more complete information on programming the bare metal. For example where does one find complete documentation of the available calls to the GPU blob (since we are stuck with this method of using the GPU).
ARM Assembly Language: For those that want: Simple, Powerful, Easy to learn, and Easy to debug.
User avatar
Posts: 1251
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
by rurwin » Mon Jun 04, 2012 4:33 pm
I would imagine the best source of information on the blob would be the device drivers on the Debian kernel for the RaspPi on github.
User avatar
Forum Moderator
Forum Moderator
Posts: 2936
Joined: Mon Jan 09, 2012 3:16 pm
by dwelch67 » Sat Jun 09, 2012 1:47 am
cheery wrote:The kernel.img is just a flat binary which gets loaded into address space starting from 0x00000000.

The first 0x20 bytes in that binary is an interrupt vector table. A trivial do-nothing program might look something like:
Code: Select all
.code 32
.org 0
    ldr pc, =reset
    nop ; undefined instruction
    nop ; software interrupt
    nop ; prefetch abort
    nop ; data abort
    nop ; ?
    nop ; IRQ
    nop ; FIQ

reset:
    b reset


Actually it is loaded at 0x8000 by default, there is a config.txt option to move it around but I was not able to get it to actually load at zero, it kept getting loaded to 0x8000. There is no need to pad your binary or branch to 0x8000, simply build your binary for a base address of 0x8000.
Posts: 433
Joined: Sat May 26, 2012 5:32 pm
by dwelch67 » Sat Jun 09, 2012 2:01 am
dwelch67 wrote:
cheery wrote:The kernel.img is just a flat binary which gets loaded into address space starting from 0x00000000.

The first 0x20 bytes in that binary is an interrupt vector table. A trivial do-nothing program might look something like:
Code: Select all
.code 32
.org 0
    ldr pc, =reset
    nop ; undefined instruction
    nop ; software interrupt
    nop ; prefetch abort
    nop ; data abort
    nop ; ?
    nop ; IRQ
    nop ; FIQ

reset:
    b reset


Actually it is loaded at 0x8000 by default, there is a config.txt option to move it around but I was not able to get it to actually load at zero, it kept getting loaded to 0x8000. There is no need to pad your binary or branch to 0x8000, simply build your binary for a base address of 0x8000.


Even better, looks like there had been some discussion. I am using boot files (bootcode.bin, loader.bin, start.elf) from github.com/raspberrypi recently downloaded. If you do not have a config.txt, etc it loads the contents of kernel.img to address 0x8000, no need for a branch, if you have linked for 0x0000 and they load to 0x8000 you have a problem. I saw a thread somewhere https://github.com/raspberrypi/linux/issues/16 talking about if you set

disable_commandline_tags=1

in config.txt then it loads at address 0x0000, and based on a quick experiment that appears to be the case. maybe in a month they will change it again and we can all start over...
Posts: 433
Joined: Sat May 26, 2012 5:32 pm
by tufty » Sat Jun 09, 2012 6:06 am
Oh, what a /TOTAL/ pain in the arse.

Good spot, Dave.
Posts: 1373
Joined: Sun Sep 11, 2011 2:32 pm
by DexOS » Sat Jun 09, 2012 4:11 pm
I am in shock :o , how can you work on a device thats setup is changing every 2 seconds.
Someone says this that and the other would be good and its added, thats just wrong, the config.txt will end up a gig in size, with so many options.

You need to know that the device your working on is a set standard, that was the advantage with the R-PI, if it worked on one R-PI it should work on all of them.

I have written a tut (not released yet) on bare metal coding and a lot now needs to be rewritten, as new stuff is coming to light.
Last edited by DexOS on Sat Jun 09, 2012 4:27 pm, edited 1 time in total.
Batteries not included, Some assembly required.
User avatar
Posts: 866
Joined: Wed May 16, 2012 6:32 pm
by cheery » Sat Jun 09, 2012 4:12 pm
dwelch67 wrote:in config.txt then it loads at address 0x0000, and based on a quick experiment that appears to be the case. maybe in a month they will change it again and we can all start over...


It's trivial to change, so I hope they'll make it as good as they can get, and then leave it alone when it's good enough.

DexOS wrote:I have written a tut (not released yet) on bare metal coding and a lot now needs to be rewritten.
I think the answer is just say no


All the changes are in the firmware yes/no? Therefore if you include the old firmware along, the image at least will keep working.
User avatar
Posts: 219
Joined: Wed Jan 25, 2012 9:39 pm
by DexOS » Sat Jun 09, 2012 4:31 pm
cheery wrote:
DexOS wrote:I have written a tut (not released yet) on bare metal coding and a lot now needs to be rewritten.
I think the answer is just say no


All the changes are in the firmware yes/no? Therefore if you include the old firmware along, the image at least will keep working.

The problem is that you would not be allowed to redistribute them, i am sure they are copy righted ?.
Batteries not included, Some assembly required.
User avatar
Posts: 866
Joined: Wed May 16, 2012 6:32 pm
by cheery » Sat Jun 09, 2012 4:45 pm
DexOS wrote:The problem is that you would not be allowed to redistribute them, i am sure they are copy righted ?.


https://github.com/raspberrypi/firmware ... E.broadcom

Code: Select all
Copyright (c) 2006, Broadcom Corporation.
All rights reserved.

Redistribution.  Redistribution and use in binary form, without
modification, are permitted provided that the following conditions are
met:

* This software may only be used for the purposes of developing for,
  running or using a Raspberry Pi device.
* Redistributions must reproduce the above copyright notice and the
  following disclaimer in the documentation and/or other materials
  provided with the distribution.
* Neither the name of Broadcom Corporation nor the names of its suppliers
  may be used to endorse or promote products derived from this software
  without specific prior written permission.

DISCLAIMER.  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.


Seems like there's no problems like that. You have the license to use it for the purpose.
User avatar
Posts: 219
Joined: Wed Jan 25, 2012 9:39 pm
by nick.mccloud » Sat Jun 09, 2012 4:49 pm
DexOS wrote:I am in shock :o , how can you work on a device thats setup is changing every 2 seconds.
Someone says this that and the other would be good and its added, thats just wrong, the config.txt will end up a gig in size, with so many options.


We are at the developer release stage - this sort of thing is bound to happen - I can appreciate it's irritating but kudos to you guys for debugging the issues at this early stage.


DexOS wrote:The problem is that you would not be allowed to redistribute them, i am sure they are copy righted ?.


As the firmware is publicly released on github and you can download older versions I can't imagine for a second that the Foundation is going to object to you taking a snapshot of the files & making them available for a good cause like a tutorial on writing bare metal code.
User avatar
Posts: 795
Joined: Sat Feb 04, 2012 4:18 pm