Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #27665

Re: How Physical Memory Mapping / Allocation works

Show all headers | View raw

On 26/02/18 23:07, Ilias Abrams wrote:
> Hi guys,
> 
> I am new on software programming and I am trying to understand some
> basic/ important things.I am interested in Bare-metal software
> programming, so please give me answers related on this. My question
> is: who is responsible and manage the physical memory mapping /
> allocation? Meaning, If I have 1GB physical memory on my system, the
> 1) CPU or 2) the Bootloader (like GRUB, U-boot)  is responsible for
> the memory addresses that I can use for my program? Is hardware
> specific architecture? Each platform manufacture has their own memory
> address mapping scheme and layout? Furthermore, is there any standart
> way that you have to partition the physical memory? meaning, give
> some memory for I/Oports and so on?
> 
> Sorry for the mess, but I dont understand when you create/ build your
> software, how you know what range of physical addresses you can use
> for start/entry point,  stack and so on.
> 
> Please help me to clear all this in my mind. If you can give me
> examples will help me more P.S. Programming in C
> 
> Thanks
> 

What sort of systems are you talking about here?  Very roughly, you can
divide processors into two categories.

There are "big" ones designed for running multiple programs from
different sources.  These use a "memory management unit" which maps the
logical addresses (seen by the program code) into physical addresses
(used by the memory itself).  The OS is responsible for setting up this
mapping, and making sure each process can only access the memory it is
allowed to use.

And there are "small" ones designed for running a single program, either
"bare metal" or with a small "real-time operating system", with all the
code compiled and linked at one time.  Then the logical addresses and
physical addresses are the same, and you often don't have any kind of
memory protection at all.


"Bare metal" programming means there is no OS or significant software
layers between the main code and the hardware - and that usually means
small devices with no memory mappings.  GB memory sizes usually means
big devices with a full OS (like Linux).  But there are some cross-over
areas - bootloaders like Grub and OS kernels are "bare metal" on the big
devices.


Memory allocation is a completely different issue.  It is always handled
by software, but may be done in different ways in different levels.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

How Physical Memory Mapping / Allocation works Ilias Abrams <iliasabrams@gmail.com> - 2018-02-26 14:07 -0800
  Re: How Physical Memory Mapping / Allocation works Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2018-02-26 21:26 -0500
  Re: How Physical Memory Mapping / Allocation works David Brown <david.brown@hesbynett.no> - 2018-02-27 08:51 +0100
    Re: How Physical Memory Mapping / Allocation works Ilias Abrams <iliasabrams@gmail.com> - 2018-02-27 02:34 -0800
      Re: How Physical Memory Mapping / Allocation works David Brown <david.brown@hesbynett.no> - 2018-02-27 14:34 +0100
        Re: How Physical Memory Mapping / Allocation works Ilias Abrams <iliasabrams@gmail.com> - 2018-02-27 10:11 -0800
          Re: How Physical Memory Mapping / Allocation works Jack <jack4747@gmail.com> - 2018-02-27 23:31 -0800
            Re: How Physical Memory Mapping / Allocation works David Brown <david.brown@hesbynett.no> - 2018-02-28 09:51 +0100
              Re: How Physical Memory Mapping / Allocation works Paul <paul@pcserviceselectronics.co.uk> - 2018-03-01 14:54 +0000
          Re: How Physical Memory Mapping / Allocation works Gunther Mannigel <newsgroups@mannigel.net> - 2018-03-03 22:54 +0100
    Re: How Physical Memory Mapping / Allocation works Ilias Abrams <iliasabrams@gmail.com> - 2018-02-27 02:36 -0800
      Re: How Physical Memory Mapping / Allocation works Mel Wilson <mwilson@the-wire.com> - 2018-02-27 16:51 +0000
      Re: How Physical Memory Mapping / Allocation works antispam@math.uni.wroc.pl - 2018-03-10 14:05 +0000
  Re: How Physical Memory Mapping / Allocation works Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-02-27 10:14 +0200

csiph-web