mrvn
Posts: 58
Joined: Wed Jan 09, 2013 6:50 pm

Bare metal: What is the power on environment?

Wed Jan 16, 2013 6:27 pm

Hi,

I'm completly new to arm and just recently got my RPi so please excuse my ignorance and feel free to throw any urls at me to read.

What I'm wondering is what environment is defined when you turn on the RPi and your bare metal kernel gets control.

So far I know the following (correct me if I get anything wrong):
  • On power on the GPU has control and does some magic stuff and evntually loads the kernel.bin from the SD card to 0x8000 and starts the ARM cpu there (r15 = 0x8000).
  • the lower 1GB address space repeats itself 4 times with different cache attirbutes, no page tables are present
  • supervisor mode (svc) is enabled
  • interrupts are disabled
  • The stack pointer (SP) is not initialized
  • 0x4000-0x8000 is free for use (e.g. as small stack)
  • UART1 is configured to 115200 8N1 (but one should initialize it again before use to be sure)
What else can you tell me about the system at that point?

I've read quite a bit about ATAGs and how they give the amount of memory the system has and the video mode and such. But no mention of where to find them on the RPi. I've read that r0, r1, r2 would contain something but no explanation what that would be. I'm guessing that would have something to do with the ATAGs. Unfortunately the example code I'm playing with use (and therefore overwrites) those registers so I can't print them to the UART for inspection later on.

How about the video output? Will the GPU have activate and configured that already at that point? Do I just need to find the ATAG, look for the ATAG_VIDEOLFB and have all the settings there? Or do I need to mess around with the mailboxes first to get the GPU to initialize video output?

Anything else noteworthy? Any "Introduction to Baremetal" post I forgot to read?

MfG
Mrvn

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

Re: Bare metal: What is the power on environment?

Wed Jan 16, 2013 7:47 pm

http://github.com/dwelch67/raspberrypi

I have various flavors of "introduction to bare metal" in the examples plus the bare metal directory and data bss, etc.

I dont think the uart is initialized, there is no bootloader (uboot) like you would see with a beagle board or the like (where the bootloader has initialized the uart).

I dont think the arm actually boots to 0x8000 but the gpu puts an instruction or two at address zero to cause the arm to jump to 0x8000. Depending on your gpu bootloader/loader version and config.txt file settings on the sd card (if you have that file) you can change where the arm program is loaded. That is a better term the arm binary (kernel.img) is "loaded" into arm address space at some address, then the gpu does whatever to cause the arm to branch to that address as needed (The arm boots from 0 when the gpu releases it from reset).

Like any 32 bit arm the stack pointer is not initialized (cortex-m it is part of the boot process) or you should assume it isnt. The stuff the gpu does is primarily geared toward booting linux, so what is required for linux to just work (the same kind of thing a bootloader like uboot would do) ATAGS at a certain address, thinks like that will be there. So if you dont care about that stuff then you can trash or reuse the 0x0000 to 0x8000 (or wherever you choose to load your arm code). My examples use it as a stack, but that can cause grief for folks that take those examples and do something else (like load the arm at 0 instead of 0x8000, thus stomping on their code if their binary is too large). Assume nothing about the arm as far as registers, etc, like any arm core you are coming out of reset in the supervisor mode and you can change modes at will, you have to setup your own stack pointers for the various modes, set up your exception table if you want interrupts supported, etc. On the good side the raspberry pi is so far unbrickable, you can make mistakes in your arm binary and not end up bricking the board like you can with others.

I have simple bare metal uart and blink the led examples. There are other folks with examples that also hang out in this forum. You have choices (and have support in this forum or directly with the developers). The ATAG stuff likely isnt used much by the bare metal folks here, but doesnt mean you cant. The video is and there are a number of tutorials and examples (I have not bothered yet), bare metal, that get graphics going.

David

User avatar
DavidS
Posts: 3800
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Bare metal: What is the power on environment?

Thu Jan 17, 2013 12:41 pm

@dwelch67:
Wow; you actually goot me to look at my ARM ARM for the first time in quite a while.

@mrvn:
ATAGS must be a linux thing.
1:) It is a good idea to reserve physical addresses 0x00000000 through 0x0000001F for the exception vector table (from the ARMs view).
2:) It can be usful to set dernel_old=1 in your CONFIG.TXT as this will load your kernel at 0x00000000, and you can hard code the initial exception vectors.
3:) Do remember that the entry points for your exception handlers must be in range of the b instruction in the exception table. This means all below address 0x00800000.

Otherwize I agree with dwelch67.
RPi = Way for me to have fun and save power.
100% Off Grid.
Household TTL Electricity Usage = 1.4KW/h per day.
500W Solar System, produces 2.8KW/h per day average.

zik
Posts: 2
Joined: Wed Jan 09, 2013 2:55 pm

Re: Bare metal: What is the power on environment?

Thu Jan 17, 2013 1:45 pm

I read the same thing about registers 0-2, however:

ARM1176JZF-S
Revision: r0p7
Technical Reference Manual

2.12.5 Reset
...
After reset, all register values except the PC and CPSR are indeterminate.

mrvn
Posts: 58
Joined: Wed Jan 09, 2013 6:50 pm

Re: Bare metal: What is the power on environment?

Thu Jan 17, 2013 1:54 pm

Thanks dwelch67 for that long reply. I had already found you treasure trove of examples but they sometimes lack a bit of documentation. For example the atags code says just:
Derived from bootloader05. This is to demonstrate the contents of the r0, r1, and r2 registers when kernel.img is entered...
Running the example gives you a number of 32bit hex values with no hint of what any of them mean.

Since then I have learned that the GPU follows the arm linux boot protocol when starting the kernel and the 3 registers are defined as:

r0 - must be zero
r1 - ARM Linux machine type
r2 - address of ATAGs

The best description of ATAGs I've found is this: http://www.simtec.co.uk/products/SWLINU ... ticle.html

Maybe you could add that info to your atags example and maybe even parse and display the atags in a human readable form.

Unfortunately the ATAGs on the RPi seems to be sparse and also broken. There only is a core, mem and command line tag and the core tag lists a page_size of 0. So it seems only 2 usefull items are there: size of memory (which can be 256MB or 512MB minus whatever the GPU takes) and the command line. No videofb tag as I would have hoped. Or do I have to put something in config.txt for the GPU to initialize the FB at boot (as opposed to later on request).

I dont think the uart is initialized, there is no bootloader (uboot) like you would see with a beagle board or the like (where the bootloader has initialized the uart).
When I first tried I only had a putc method for the UART and everything worked. I added init code later for good measure but it doesn't seem neccessary. So either the GPU initializes the UART or the power on settings default to something usable.
I dont think the arm actually boots to 0x8000 but the gpu puts an instruction or two at address zero to cause the arm to jump to 0x8000.
Doing a hex dump of the 0x000-0x4000 shows that there are a few bytes set at 0x000 and then the ATAGs starting at 0x100 and nothing else. Might be worth putting the first few bytes through a disassembler. Has anyone done that?

MfG
Mrvn

BrianW
Posts: 83
Joined: Sun Jul 29, 2012 9:03 pm

Re: Bare metal: What is the power on environment?

Thu Jan 17, 2013 1:56 pm

mrvn wrote:
  • the lower 1GB address space repeats itself 4 times with different cache attirbutes, no page tables are present
The address space repeats itself, but the cache attributes are for the VideoCore MMU. The ARM MMU and cache are turned off.
  • supervisor mode (svc) is enabled
  • interrupts are disabled
  • The stack pointer (SP) is not initialized
Correct
  • 0x4000-0x8000 is free for use (e.g. as small stack)
Yes. The only thing the ARM needs is the exception vectors at 0x0000 - 0x001f. Anything else is fair game.
I've read quite a bit about ATAGs and how they give the amount of memory the system has and the video mode and such. But no mention of where to find them on the RPi. I've read that r0, r1, r2 would contain something but no explanation what that would be. I'm guessing that would have something to do with the ATAGs. Unfortunately the example code I'm playing with use (and therefore overwrites) those registers so I can't print them to the UART for inspection later on.
  • r0 is always 0
  • r1 is the address of the ATAGs. It's always 0x00000100 (which is pretty common on ARM machines), but you should probably use r1 to find it rather than assuming it's there.
  • r2 is the machine type. For a Raspberry Pi, this will be 0x0c42 ("Broadcom BCM2708 Video Coprocessor") - http://www.arm.linux.org.uk/developer/machines/
ATAGs give various of bits system information. The ones the Pi provides are "core" (though the values are invalid, so ignore it), memory, commandline and initial ramdisk (if specified in config.txt).

The memory information is available through the property mailbox interface. The command line is too, but the command line in ATAGs is longer (it has an extra load of Linux boot information set by the bootloader, while the property mailbox version just contains the string in cmdline.txt).
How about the video output? Will the GPU have activate and configured that already at that point? Do I just need to find the ATAG, look for the ATAG_VIDEOLFB and have all the settings there? Or do I need to mess around with the mailboxes first to get the GPU to initialize video output?
ATAG_VIDEOLFB isn't used.

The GPU seems to set up the screen's physical size, and a framebuffer with a virtual resolution of 2x2. This means you get 4 massive pixels, which, by default, are red, green, blue and yellow.

To set up the screen, you can read its size from either the properties mailbox or the kernel command line in ATAG_CMDLINE. If you're using the properties mailbox approach, the bare minimum seems to be to set the virtual size to match the physical size (unless you're planning to do something which requires it to be some other size), request the allocation of a framebuffer, and read in the screen pitch (bytes/line). If you're using the framebuffer mailbox, you put all the values in at once and (hopefully) get an allocated framebuffer back.

Example here: https://github.com/brianwiddas/pi-barem ... mebuffer.c

BrianW
Posts: 83
Joined: Sun Jul 29, 2012 9:03 pm

Re: Bare metal: What is the power on environment?

Thu Jan 17, 2013 1:59 pm

zik wrote:I read the same thing about registers 0-2, however:

ARM1176JZF-S
Revision: r0p7
Technical Reference Manual

2.12.5 Reset
...
After reset, all register values except the PC and CPSR are indeterminate.
Bear in mind that that your code isn't loaded into an unconfigured device; before the ARM processor is started, the VideoCore GPU plants some code at 0x00000000 (the reset vector) to set up r0, r1, and r2, then jump to your kernel at 0x00008000.

BrianW
Posts: 83
Joined: Sun Jul 29, 2012 9:03 pm

Re: Bare metal: What is the power on environment?

Thu Jan 17, 2013 2:05 pm

DavidS wrote: 3:) Do remember that the entry points for your exception handlers must be in range of the b instruction in the exception table. This means all below address 0x00800000.
The ARM1176 lets you move the exception vector table. I've put the kernel at 0xf0000000 and moved the exception vectors to an address in there

Code: Select all

asm volatile("mcr p15, 0, %[addr], c12, c0, 0" : : [addr] "r" (&interrupt_vectors));
https://github.com/brianwiddas/pi-barem ... terrupts.c

User avatar
DavidS
Posts: 3800
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Bare metal: What is the power on environment?

Fri Jan 18, 2013 3:32 am

I am aware that the ARM1176 does allow the relocation of the exception table base, I figured it better to not get into that sub discution, especialy with a bare metel noob. We do not want them to think that you can do that on all ARM based systems (and detecting the processor type just you know where you can put your kernel is a bit of an archane art [a bit better if you are willing to slow thins down a tad by putting routines to call out to the real handlers on CPUs that do not suport this relocation]).
RPi = Way for me to have fun and save power.
100% Off Grid.
Household TTL Electricity Usage = 1.4KW/h per day.
500W Solar System, produces 2.8KW/h per day average.

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

Re: Bare metal: What is the power on environment?

Fri Jan 18, 2013 3:58 pm

The ARM's that I have seen that allow for an alternate exception table startup address, are selected using a strap on the core. If the chip vendor has tied that strap and not provided a way to modify it before releasing reset then you get whatever their strap option is. Naturally they can also design their memory controller such that it sees address 0 and based on straps or other settings maps that to some other address space, or vary what that maps to. Many microcontrollers do this.

I think the issue here is that there is the allusion that the arm is booting at some non normal address which is not the case. The kernel.img is LOADED somewhere, 0x0000, 0x8000, etc and you can change that, but that does not change how the arm core boots. I so far have not heard of an arm core where you can change the exception table base to anything you want, just the single bit strap giving two choices (zero or something high up starting with 0xFs).

David

BrianW
Posts: 83
Joined: Sun Jul 29, 2012 9:03 pm

Re: Bare metal: What is the power on environment?

Fri Jan 18, 2013 4:15 pm

dwelch67 wrote:I think the issue here is that there is the allusion that the arm is booting at some non normal address which is not the case. The kernel.img is LOADED somewhere, 0x0000, 0x8000, etc and you can change that, but that does not change how the arm core boots. I so far have not heard of an arm core where you can change the exception table base to anything you want, just the single bit strap giving two choices (zero or something high up starting with 0xFs).
In addition to 0xffff0000, the ARM1176TZJ-S gives you the option of moving the exception base table anywhere in memory (as long as it's aligned to 32 bytes) by setting the vector base address register in the system co-processor (CP15, C12).

It doesn't change how the ARM boots (it will still boot from 0x00000000), the booted kernel can then shift all subsequent exceptions to some other memory location.

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: Bare metal: What is the power on environment?

Fri Jan 18, 2013 6:19 pm

DavidS wrote:3:) Do remember that the entry points for your exception handlers must be in range of the b instruction in the exception table. This means all below address 0x00800000.
Not entirely true - it's relatively common practice to use a construct like this, which allows any location for the various handlers, and "hot patching" of the handler addresses without having to synthesize instructions:

Code: Select all

__reset:
	ldr	pc, reset_handler_address
	ldr	pc, undef_handler_address
	ldr	pc, svc_handler_address
	ldr	pc, prefetch_abort_handler_address
	ldr	pc, data_abort_handler_address
_loop:	b	.
	ldr	pc, irq_handler_address
	ldr	pc, fiq_handler_address

reset_handler_address:		.word	_reset
undef_handler_address:		.word	__undef
svc_handler_address:		.word	_svc
prefetch_abort_handler_address:	.word	__prefetch_abort
data_abort_handler_address:	.word	__data_abort
unused:				.word   _loop
irq_handler_address:		.word	_irq
fiq_handler_address:		.word	_fiq

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

Re: Bare metal: What is the power on environment?

Fri Jan 18, 2013 6:41 pm

DavidS wrote:Do remember that the entry points for your exception handlers must be in range of the b instruction in the exception table. This means all below address 0x00800000.
The instructions in the exception table *IFF* you are supporting the location or locations after that entry, must be a single instruction branch. You have two primary choices for this, an unconditional branch (b) or a load pc (ldr pc). The unconditional branch is clean and tidy and self contained, but limited reach, the ldr pc, requires another memory location also near by, but gives you complete range. Unless you move your whole binary the unconditional branch is position specific, where the ldr pc is position independent.

If you are not using the exception table for example you only care about reset, you can simply just have your reset handler start at zero, no branching required. (can make debugging more difficult down the road if aborts or other exceptions start execution in the middle of your code, if lucky it looks like your arm keeps rebooting).

This is an interesting difference that you seen in the classic arm architecture which you dont normally see elsewhere, ARM executes the item in the table, where other architectures the table is a list of addresses which tell you where to find the code. (Note ARM's cortex-m switched to the address based approach)

User avatar
DavidS
Posts: 3800
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Bare metal: What is the power on environment?

Fri Jan 18, 2013 7:46 pm

dwelch67 wrote:..... Unless you move your whole binary the unconditional branch is position specific, where the ldr pc is position independent. .....
What?
The b instruction is relitive to its current location, the ldr r15 is tied to the absolute address stored at the location that it is loaded from. I must be missing something, though I would think that this would make the ldr r15 instruction more position dependant than the b instruction.

You are speaking about the dependance on the location of execution, correct? And it is logical to code the core handlers as position idependant code (in case it has to run on one of the wierd systems that put the exception table some where other than 0, and do not allow for it to be at 0), correct?

If so then you would wish your exception handling code and exception table to be able to be anywhere in memory with out having it t be modified. This is easiest to do this is to have the core of the handlers in memory close to the top of the exception vectors, and code the core of the handlers to be position independant.

Where needed the core handlers can easily branch into the kernel, no matter where the kernel is (so long as they know where the kernel is).
RPi = Way for me to have fun and save power.
100% Off Grid.
Household TTL Electricity Usage = 1.4KW/h per day.
500W Solar System, produces 2.8KW/h per day average.

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

Re: Bare metal: What is the power on environment?

Fri Jan 18, 2013 8:18 pm

If I have a b instruction that I want at 0x8000 that branches to 0x9000 and link it as such, then if I copy that exception table to 0x0000 the b instruction will branch to 0x1000 where I dont have handler, crash. (unless the whole binary is copied, which is what I said, then the whole binary has to be position independent)

if I take a ldr pc instruction at 0x8000 and have it load the value at 0x8040 (0x9000) into the pc, and link it as such, and take both of those words and copy them to 0x0000 and 0x0040 then when ldr pc now at 0x0000 is executed it loads the value 0x9000 into the pc and goes to my handler without having to move the whole binary and without having to have the whole binary position independent. You can let the linker do all the work of filling in the addresses to handlers, and you only have to copy the exception table and the list of addresses to 0x0000 not the whole binary.

dwelch67

mrvn
Posts: 58
Joined: Wed Jan 09, 2013 6:50 pm

Re: Bare metal: What is the power on environment?

Fri Jan 18, 2013 9:22 pm

BrianW wrote:
mrvn wrote:How about the video output? Will the GPU have activate and configured that already at that point? Do I just need to find the ATAG, look for the ATAG_VIDEOLFB and have all the settings there? Or do I need to mess around with the mailboxes first to get the GPU to initialize video output?
ATAG_VIDEOLFB isn't used.

The GPU seems to set up the screen's physical size, and a framebuffer with a virtual resolution of 2x2. This means you get 4 massive pixels, which, by default, are red, green, blue and yellow.
That doesn't appear to be the case. When I boot my mini kernel (which does nothing with the GPU yet) and switch to the hdmi output of my RPi then I get a big colored square with red, yellow, blue and cyan in the corners and colors fading smoothly. So more than 2x2 pixel unless the hardware scaling also interpolates colors. Does it?

Maybe I have newer firmware?
BrianW wrote: To set up the screen, you can read its size from either the properties mailbox or the kernel command line in ATAG_CMDLINE. If you're using the properties mailbox approach, the bare minimum seems to be to set the virtual size to match the physical size (unless you're planning to do something which requires it to be some other size), request the allocation of a framebuffer, and read in the screen pitch (bytes/line). If you're using the framebuffer mailbox, you put all the values in at once and (hopefully) get an allocated framebuffer back.

Example here: https://github.com/brianwiddas/pi-barem ... mebuffer.c
*bookmarked*
I was wondering how to get the monitors size because the examples I looked at simply requested a fixed size of their choosing.

Is querying the initial size and simply using that the recommended way or is there also a call to query the monitors capabilities? I have to confess I haven't yet looked at the mailbox stuff for the GPU in detail. Just skimmed an example or two. So if that's a RTFM just say so.

BrianW
Posts: 83
Joined: Sun Jul 29, 2012 9:03 pm

Re: Bare metal: What is the power on environment?

Fri Jan 18, 2013 9:30 pm

mrvn wrote:So more than 2x2 pixel unless the hardware scaling also interpolates colors. Does it?
Yes, it does. I wasn't clear on that point - they are 4 giant virtual pixels that are interpolated over the display.
Is querying the initial size and simply using that the recommended way or is there also a call to query the monitors capabilities?
It's the best way I've found so far. Information about setting up the display seems to be hard to find; it took a bit of trial-and-error to get the display working for me.

User avatar
DavidS
Posts: 3800
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Bare metal: What is the power on environment?

Fri Jan 18, 2013 9:43 pm

dwelch67 wrote:If I have a b instruction that I want at 0x8000 that branches to 0x9000 and link it as such, then if I copy that exception table to 0x0000 the b instruction will branch to 0x1000 where I dont have handler, crash. (unless the whole binary is copied, which is what I said, then the whole binary has to be position independent)

if I take a ldr pc instruction at 0x8000 and have it load the value at 0x8040 (0x9000) into the pc, and link it as such, and take both of those words and copy them to 0x0000 and 0x0040 then when ldr pc now at 0x0000 is executed it loads the value 0x9000 into the pc and goes to my handler without having to move the whole binary and without having to have the whole binary position independent. You can let the linker do all the work of filling in the addresses to handlers, and you only have to copy the exception table and the list of addresses to 0x0000 not the whole binary.

dwelch67
Ok you are saying that you are assembling the exception handlers as part of your kernel that is running at 0x8000, and liking them rlitive to that. I whas saying that the core of the exception handlers should be a small peice that is assembled and linked to a base of 0x00000000 and includes the eception table at the beginning. This binary could be copied to address 0x00000000 with no dificulty (or any where else [so long as the code in this very small binary is position independant]). Any exception that requires more intencive handling is then passed on from there to the kernel (or other apropriate module/handler).

The core exception handlers should not be more than 4KB which still comes under your 0x00008000 (0x8000 bytes = 32KB). Ususlly the core exception handlers in my systems total to under 2KB (512 32bit words).


The missunderstanding seems to be to due with the difference between hardlinking relitive to the kernel, versus a seperately linked binary (that can be held in the kernel before it is copied) linked to 0x00000000.
RPi = Way for me to have fun and save power.
100% Off Grid.
Household TTL Electricity Usage = 1.4KW/h per day.
500W Solar System, produces 2.8KW/h per day average.

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

Re: Bare metal: What is the power on environment?

Fri Jan 18, 2013 10:01 pm

Right instead of a whole kernel (small or large) with handlers that has to be moved to zero after boot (or system forced to load it there). what *we* are talking about (wasnt just me) is to have twice the size of the exception table be all that you need to copy to zero with half of that content being filled in by the linker. You dont need a kernel and ways to register interrupt handlers, etc.

I guess it is a bare metal model vs an operating system model type approach. The solution we are talking about relies on having ram at address zero, an approach I have used and no doubt others would be the opposite, in the rom based exception table

b reset
ldr pc,handler_a
ldr pc,handler_b
...

handler_a: ram_base+0x40
handler_b: ram_base+0x44
...

then in the ram based binary

b over
ldr pc,handler_a
ldr pc,handler_b
...

handler_a: handler_a_address
handler_b: handler_b_address
...

over:

The binary when compiled for ram can be tested using a bootloader (that would have the above exception table allowing this all to work). Then once tested and ready to deploy you can re-link using the rom base address for .text. Load it into rom and test enough to make sure the .text/.data split worked unless that was already tested before (with .data being somewhere else and not moving).

Sure you could take the other approach as well

rom:

b reset
b rambase+4
b rambase+8
...

ram
b reset
b handler_a
b handler_b
...

The whole point though is that using ldr pc in a ram based (address 0) system, you can let the linker do most of the work and simply copy twice the exception table size to ram and be done. No need to copy any additional handler code or handler registration code or anything like that.

dwelch67

User avatar
DavidS
Posts: 3800
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Bare metal: What is the power on environment?

Fri Jan 18, 2013 10:27 pm

Ok sensable.

I use b instructions with nearby handler code, as better than 90% of exceptions can be completely handled in the small handler, and less than 10% have to be dspached elseware, so for those 90%+ that extra memory access to LDR PC, can be a noticable slow down (something like 3ns per access I think).

I can see the merrit using ldr r15 if you are just playing around with bare metal programming rather than writing a complete Operating System.
RPi = Way for me to have fun and save power.
100% Off Grid.
Household TTL Electricity Usage = 1.4KW/h per day.
500W Solar System, produces 2.8KW/h per day average.

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

Re: Bare metal: What is the power on environment?

Sat Jan 19, 2013 3:14 am

whatever, you win (despite the vast quantities of bare metal arm code on the net), I give up.

Note this is a bare metal forum for people that are both learning and playing around with bare metal. The title of this forum is not homebrew os.

dwelch67

User avatar
DavidS
Posts: 3800
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Bare metal: What is the power on environment?

Sat Jan 19, 2013 3:49 am

I had no interest in arguing. Each person has a different whay of doing things. I was first attempting to understand your point of view. Once I did so understand my two following posts
were intend to convey my thanks for the alternate perspective.

I have been coding on ARM's for about 20 years, remember that the philosophy has changed somewhat in this time. As a result sometimes something that may now be widely accepted will sometimes completely through me off balance, so I will attempt to understand.

If I feel that a discution has become non productive, or a belief of one way is better than another (which is almost never true) I will leave the discution on a polite note.

I do understand your (and a few others) view on this topic.
I GIVE MY APPOLOGY FOR ANYTHING THAT I MAY HAVE SAID THAT WAS FELT TO BE OFFENCIVE AND OR FELT TO BE PUSHING TOWORD A SINGULAR VIEW. This was never my intent. I am well aware that my interpersonal skills are terible. If you feel that I am pushing, or being offencive it would be greately apreciated if you would let me know in a PM.

PS. I must apologize for having to post this in the middle of this thread, I was unable to send it as a PM.
Apologies and Thank you.

Now Let us attempt to get this thread back on topic.
RPi = Way for me to have fun and save power.
100% Off Grid.
Household TTL Electricity Usage = 1.4KW/h per day.
500W Solar System, produces 2.8KW/h per day average.

Return to “Bare metal, Assembly language”