Re: Re: Fwd: memory probing

Re: Re: Fwd: memory probing

[coly li]

alfred hitch:

Bios can provide us a memory map table, for it knows the initial address space layout, why it knows, because bios itself does the initial mapping for address space.

In a non-bios enviornment, we can't get the memory map table by calling bios service, so, we have to detect the size of memory by ourselves.

write and verify means: you read the content from location X, and change the value, then write back to location X; then re-read the content from X, if the value is what you write, the location X is valid; otherwise, maybe the location X is invalid.

as a trick, you need not verify the memory linearly, you can verify it in the power-of-two, only perform linearly dectecting after the prior detecting failed. 
				 
　　　　　　　　coly li
　　　　　　　　colyli@263.net
　　　　　　　　　　2005-05-10


======= 2005-05-10 16:33:25 original messages：=======

>thanks,
>but what did u mean write and verify, 
>I thhot grub depends heavilly on bios calls for all this .. 
>
>Alfred
>
>On 5/10/05, coly li <colyli@263.net> wrote:
>> alfred hitch:
>> 
>> It's not so easy to get the proper answer. it depends on your hardware. for I'm not familiar with embedded enviornmnet, I can only give you some idea for x86 platform.
>> 
>> you should know your memory address space layouts. which range is for other peripheral, which range is for real memory. different range use difference detecting scheme. for the range of real memory, the simplest method is "write and verify".
>> 
>> but, for I'm not a embedded programmer, I can't give you more information for non-x86. FYI.
>> 
>> coly li
>> colyli@263.net
>> 2005-05-10
>> 
>> ======= 2005-05-10 14:36:51 original messages：=======
>> 
>> >---------- Forwarded message ----------
>> >From: alfred hitch <alfred.hitch@gmail.com>
>> >Date: May 10, 2005 2:13 AM
>> >Subject: Re: memory probing
>> >To: The development of GRUB 2 <grub-devel@gnu.org>
>> >
>> >
>> >Hi,
>> >
>> >thanks for your response,
>> >actually what I am looking for is that does grub and all use bios
>> >calls to find out the memory size ?
>> >on my system there is no bios, ixdp425 based plattform,
>> >then can I somehow probe amount of memory and not use a #define'ed one ?
>> >
>> >Cheers,
>> >Alfred
>> >
>> >On 5/10/05, coly li <colyli@263.net> wrote:
>> >> alfred hitch:
>> >>
>> >> hi! I guess what you want to know more is the initialization for linux kernel.
>> >> I know a guy who wirtes a perfect text named "i386 linux boot howto", you can find out this text on www.tldp.org.
>> >> also, I sugest you read the linux boot protocol, you can find this text in linux kenrel source code. maybe the name is boot.txt.
>> >>
>> >> good luck;-)
>> >>
>> >> coly li
>> >> colyli@263.net
>> >> 2005-05-10
>> >>
>> >> ======= 2005-05-10 12:08:54 original messages：=======
>> >>
>> >> >Hi All,
>> >> >
>> >> >I am trying to understand working of bootloaders and have a question
>> >> >(which might be very elementary perhaps).
>> >> >
>> >> >I wanted to understand how does bootloaders probe memory installed on
>> >> >system and thus pass the correct mem option across to linux kernel
>> >> >say.
>> >> >
>> >> >Can someone please explain if this is dependant on bios necessarilly,
>> >> >as I am looking for doing something similar on ixdp425 plattform.
>> >> >
>> >> >Can u please point me to some relavant doc / code ..
>> >> >
>> >> >Cheers,
>> >> >Alfred
>> >> >
>> >> >
>> >> >_______________________________________________
>> >> >Grub-devel mailing list
>> >> >Grub-devel@gnu.org
>> >> >http://lists.gnu.org/mailman/listinfo/grub-devel
>> >>
>> >> = = = = = = = = = = = = = = = = = = = =
>> >>
>> >>
>> >> _______________________________________________
>> >> Grub-devel mailing list
>> >> Grub-devel@gnu.org
>> >> http://lists.gnu.org/mailman/listinfo/grub-devel
>> >>
>> >>
>> >>
>> >
>> >
>> 
>> = = = = = = = = = = = = = = = = = = = =
>> 
>>

= = = = = = = = = = = = = = = = = = = =
	

Re: Fwd: memory probing

[Marco Gerards]

"coly li" <colyli@263.net> writes:

> write and verify means: you read the content from location X, and
> change the value, then write back to location X; then re-read the
> content from X, if the value is what you write, the location X is
> valid; otherwise, maybe the location X is invalid.

This sounds dangerous to me, what if you are writing to memory mapped
I/O?  I think you can get the amount of memory from the processor, no?

--
Marco

Re: Fwd: memory probing

[alfred hitch]

I agree with u, 
if there are holes and all in the area being scanned also with this fail ?

anyways, how can u get this from processor also ? 
I vaguely remember see'ing some code where someone on a i386 based
plattform but WITHOUT bios, used smbus protocol to talk to a device
across PIIX4 to get the info.

I am not familiar with PC architecture, so can someone tell me if
there is some standard chip  (memory controller? ?) where one can read
this on PC type arch. atleast ?

I am on  a IXDP425 plattform, and so far I cannot see any such
register on the data sheets ..

Cheers,
Alfred

On 5/10/05, Marco Gerards <metgerards@student.han.nl> wrote:
> "coly li" <colyli@263.net> writes:
> 
> > write and verify means: you read the content from location X, and
> > change the value, then write back to location X; then re-read the
> > content from X, if the value is what you write, the location X is
> > valid; otherwise, maybe the location X is invalid.
> 
> This sounds dangerous to me, what if you are writing to memory mapped
> I/O?  I think you can get the amount of memory from the processor, no?
> 
> --
> Marco
> 
>

Re: Fwd: memory probing

[Stefan Reinauer]

* alfred hitch <alfred.hitch@gmail.com> [050510 12:23]:
> anyways, how can u get this from processor also ? 

The processor has little to nothing to do with this.. it's dependent on
the northbridge and southbridge.

> I vaguely remember see'ing some code where someone on a i386 based
> plattform but WITHOUT bios, used smbus protocol to talk to a device
> across PIIX4 to get the info.
 
Which might work on one motherboard and fail on another. Even if they
both have a PIIX4.

> I am not familiar with PC architecture, so can someone tell me if
> there is some standard chip  (memory controller? ?) where one can read
> this on PC type arch. atleast ?

No. Not in a portable way. That's why BIOS provides the e820 table.

> I am on  a IXDP425 plattform, and so far I cannot see any such
> register on the data sheets ..
 
They are usually not disclosed in publically available datasheets.

  Stefan

Re: Fwd: memory probing

[alfred hitch]

Hi Stefan,

thanks for your reply, 
but I am still not very clear on how this is done by say bios on x86
plattforms, ?
can u please expain in more detail abt this north bridge , south
bridge thing .. ?

I would like to try and recreate the same way of probing for our set
up, may be its not that portable , but atleast works on our series of
products ..

What registers are these ? 

Cheers,
Alfred

On 5/10/05, Stefan Reinauer <stepan@openbios.org> wrote:
> * alfred hitch <alfred.hitch@gmail.com> [050510 12:23]:
> > anyways, how can u get this from processor also ?
> 
> The processor has little to nothing to do with this.. it's dependent on
> the northbridge and southbridge.
> 
> > I vaguely remember see'ing some code where someone on a i386 based
> > plattform but WITHOUT bios, used smbus protocol to talk to a device
> > across PIIX4 to get the info.
> 
> Which might work on one motherboard and fail on another. Even if they
> both have a PIIX4.
> 
> > I am not familiar with PC architecture, so can someone tell me if
> > there is some standard chip  (memory controller? ?) where one can read
> > this on PC type arch. atleast ?
> 
> No. Not in a portable way. That's why BIOS provides the e820 table.
> 
> > I am on  a IXDP425 plattform, and so far I cannot see any such
> > register on the data sheets ..
> 
> They are usually not disclosed in publically available datasheets.
> 
>   Stefan
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: Fwd: memory probing

[Douglas Wade Needham]

First the northbridge/southbridge.  Here is a pic..


                                    +--------+  +----------+
                                    |  CPU   |--| L2 CACHE |
                                    +--------+  +----------+
                                        |
                                        |  CPU Bus
                                        |
                                 +-------------+    +-----+
                                 | Northbridge |----| RAM |
                                 +-------------+    +-----+
                                        |
                                        | Local Bus (typ. PCI)
                                        |
                                 +-------------+
                                 | Southbridge |
                                 +-------------+
                                        |
                                        |
                                        | Periph Bus (PCI, ISA.)
                                        |

The northbridge is primarily responsible for memory control, as well
as providing a common bus for other controllers and bridge chips.
Most of the time, this is a PCI bus.  The southbridge, OTOH is the one
which is more versatile, typically acting as a bridge between the
intermediate bus and other busses used for peripherals (ISA, PCI,
etc.).  Since fewer chips is often a major design goal, the
southbridge also tends to include things like an IDE controller,
floppy controller, COM ports, etc.  In some cases, the north and south
bridges may be combined into a single chip.  In other cases (such as
on the MCP-750), the northbridge is actually split in two, and the
local bus functionallity is separated from the memory controller
function, and both talk directly to the CPU.

As for details on your bridge chips, you will probably need to do a
NDA with some vendor to get the spec sheets which tell you the
details.  The chip which has responsibility for the memory, which is
generally your northbridge (such as a Intel 440BX), will during
initialization do reads of special info on your memory modules using
I2C cycles.  As a result, this chip can determine parameters such as
RAM speed, size, etc.  Some bridge chips will do this as a result of a
reset, while others may require a command to be issued to do this.
Now from what I have seen, more will do it automatically when the reset
signal is asserted, instead of requiring for a command to be issued.

BTW...reading this sort of information is generally done by the boot
firmware (e.g. "BIOS"), as it is often needed so that it knows where
the bootstrap can be loaded.  It is also sometimes the case that the
bootstrap will not read this information itself, but will instead
either be passed the info, or will load the main program (kernel,
etc.) based upon a set of assumptions.

- Doug

Quoting alfred hitch (alfred.hitch@gmail.com):
> Hi Stefan,
> 
> thanks for your reply, 
> but I am still not very clear on how this is done by say bios on x86
> plattforms, ?
> can u please expain in more detail abt this north bridge , south
> bridge thing .. ?
> 
> I would like to try and recreate the same way of probing for our set
> up, may be its not that portable , but atleast works on our series of
> products ..
> 
> What registers are these ? 
> 
> Cheers,
> Alfred
> 
> On 5/10/05, Stefan Reinauer <stepan@openbios.org> wrote:
> > * alfred hitch <alfred.hitch@gmail.com> [050510 12:23]:
> > > anyways, how can u get this from processor also ?
> > 
> > The processor has little to nothing to do with this.. it's dependent on
> > the northbridge and southbridge.
> > 
> > > I vaguely remember see'ing some code where someone on a i386 based
> > > plattform but WITHOUT bios, used smbus protocol to talk to a device
> > > across PIIX4 to get the info.
> > 
> > Which might work on one motherboard and fail on another. Even if they
> > both have a PIIX4.
> > 
> > > I am not familiar with PC architecture, so can someone tell me if
> > > there is some standard chip  (memory controller? ?) where one can read
> > > this on PC type arch. atleast ?
> > 
> > No. Not in a portable way. That's why BIOS provides the e820 table.
> > 
> > > I am on  a IXDP425 plattform, and so far I cannot see any such
> > > register on the data sheets ..
> > 
> > They are usually not disclosed in publically available datasheets.
> > 
> >   Stefan
> > 
> > 
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > http://lists.gnu.org/mailman/listinfo/grub-devel
> >
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

-- 
Douglas Wade Needham - KA8ZRT        UN*X Consultant & UW/BSD kernel programmer
Email:  cinnion @ ka8zrt . com       http://cinnion.ka8zrt.com
Disclaimer: My opinions are my own.  Since I don't want them, why
            should my employer, or anybody else for that matter! 

Re: Fwd: memory probing

[alfred hitch]

Hi Doug,

thanks a lot for your explanation, it explains quite well now to me
the x86 arch.

Ok coming back to the discussion, sau bios reads this info from north
bridge, north bridge gets this across reboots from memory module using
i2c.

so, basically the info is coming from the memory chip ?
We are using micron chips /banks and I just checked their data sheet,
I dont see any such register there ..
I see only memory init sequences etc .. 

In IXP data sheet memory controller section mentions only one register
saying size and that is being overwritten by value from bootloader
(hard coded compile time #define)
2 other registes are to talk to / initiate state machine of dram init
seq, etc ..

Seem to me a dead wall ahead -;)

Alfred

So, I am feeling now that this plattform

On 5/11/05, Douglas Wade Needham <site.grub@ka8zrt.com> wrote:
> First the northbridge/southbridge.  Here is a pic..
> 
>                                     +--------+  +----------+
>                                     |  CPU   |--| L2 CACHE |
>                                     +--------+  +----------+
>                                         |
>                                         |  CPU Bus
>                                         |
>                                  +-------------+    +-----+
>                                  | Northbridge |----| RAM |
>                                  +-------------+    +-----+
>                                         |
>                                         | Local Bus (typ. PCI)
>                                         |
>                                  +-------------+
>                                  | Southbridge |
>                                  +-------------+
>                                         |
>                                         |
>                                         | Periph Bus (PCI, ISA.)
>                                         |
> 
> The northbridge is primarily responsible for memory control, as well
> as providing a common bus for other controllers and bridge chips.
> Most of the time, this is a PCI bus.  The southbridge, OTOH is the one
> which is more versatile, typically acting as a bridge between the
> intermediate bus and other busses used for peripherals (ISA, PCI,
> etc.).  Since fewer chips is often a major design goal, the
> southbridge also tends to include things like an IDE controller,
> floppy controller, COM ports, etc.  In some cases, the north and south
> bridges may be combined into a single chip.  In other cases (such as
> on the MCP-750), the northbridge is actually split in two, and the
> local bus functionallity is separated from the memory controller
> function, and both talk directly to the CPU.
> 
> As for details on your bridge chips, you will probably need to do a
> NDA with some vendor to get the spec sheets which tell you the
> details.  The chip which has responsibility for the memory, which is
> generally your northbridge (such as a Intel 440BX), will during
> initialization do reads of special info on your memory modules using
> I2C cycles.  As a result, this chip can determine parameters such as
> RAM speed, size, etc.  Some bridge chips will do this as a result of a
> reset, while others may require a command to be issued to do this.
> Now from what I have seen, more will do it automatically when the reset
> signal is asserted, instead of requiring for a command to be issued.
> 
> BTW...reading this sort of information is generally done by the boot
> firmware (e.g. "BIOS"), as it is often needed so that it knows where
> the bootstrap can be loaded.  It is also sometimes the case that the
> bootstrap will not read this information itself, but will instead
> either be passed the info, or will load the main program (kernel,
> etc.) based upon a set of assumptions.
> 
> - Doug
> 
> Quoting alfred hitch (alfred.hitch@gmail.com):
> > Hi Stefan,
> >
> > thanks for your reply,
> > but I am still not very clear on how this is done by say bios on x86
> > plattforms, ?
> > can u please expain in more detail abt this north bridge , south
> > bridge thing .. ?
> >
> > I would like to try and recreate the same way of probing for our set
> > up, may be its not that portable , but atleast works on our series of
> > products ..
> >
> > What registers are these ?
> >
> > Cheers,
> > Alfred
> >
> > On 5/10/05, Stefan Reinauer <stepan@openbios.org> wrote:
> > > * alfred hitch <alfred.hitch@gmail.com> [050510 12:23]:
> > > > anyways, how can u get this from processor also ?
> > >
> > > The processor has little to nothing to do with this.. it's dependent on
> > > the northbridge and southbridge.
> > >
> > > > I vaguely remember see'ing some code where someone on a i386 based
> > > > plattform but WITHOUT bios, used smbus protocol to talk to a device
> > > > across PIIX4 to get the info.
> > >
> > > Which might work on one motherboard and fail on another. Even if they
> > > both have a PIIX4.
> > >
> > > > I am not familiar with PC architecture, so can someone tell me if
> > > > there is some standard chip  (memory controller? ?) where one can read
> > > > this on PC type arch. atleast ?
> > >
> > > No. Not in a portable way. That's why BIOS provides the e820 table.
> > >
> > > > I am on  a IXDP425 plattform, and so far I cannot see any such
> > > > register on the data sheets ..
> > >
> > > They are usually not disclosed in publically available datasheets.
> > >
> > >   Stefan
> > >
> > >
> > > _______________________________________________
> > > Grub-devel mailing list
> > > Grub-devel@gnu.org
> > > http://lists.gnu.org/mailman/listinfo/grub-devel
> > >
> >
> >
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > http://lists.gnu.org/mailman/listinfo/grub-devel
> 
> --
> Douglas Wade Needham - KA8ZRT        UN*X Consultant & UW/BSD kernel programmer
> Email:  cinnion @ ka8zrt . com       http://cinnion.ka8zrt.com
> Disclaimer: My opinions are my own.  Since I don't want them, why
>             should my employer, or anybody else for that matter!
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: Fwd: memory probing

[Douglas Wade Needham]

Quoting alfred hitch (alfred.hitch@gmail.com):
> Hi Doug,
> 
> thanks a lot for your explanation, it explains quite well now to me
> the x86 arch.

It is not just the x86, but the same is true of other architectures
such as the PPC (PREP/CHRP or not), 68K, VAX or any other CPU
architecture.  You have a CPU core, and connected to it via some
processor specific bus you have a memory controller and some form of
logic to convert from that processor specific bus to a more open bus
architecture such as PCI (or ISA/EISA, MCA, VME, etc.).  And indeed,
this is true even in cases where the CPU chip/module incorporates the
memory controller and perhaps even presents just a bus such as PCI.  I
have dealt with so many different CPU architectures over the years,
and have seen such a case.  This is because space on a board and
routing the signals costs money.  So just like the NB and SB chips are
sometimes combined, sometimes the process goes to the extreme and
everything is on a single chip.

BTW...if you want to learn more about computer architecture at this
level, you can find all sorts of stuff in books and in data sheets on
the web.

> Ok coming back to the discussion, sau bios reads this info from north
> bridge, north bridge gets this across reboots from memory module using
> i2c.
> 
> so, basically the info is coming from the memory chip ?
> We are using micron chips /banks and I just checked their data sheet,
> I dont see any such register there ..
> I see only memory init sequences etc .. 

This is correct.  If you see terms like serial presence-detect, SPD or
other names, this is what is being referred to.  Indeed, even the old
100-pin DIMMs had this functionallity.  Just take a look at this page,
and go to the data sheets...

    http://www.micron.com/products/modules/sdram/partlist.aspx

And in case you are wondering, the old 72 and 36 pin DIMMs had
dedicated pins which were either at voltage or ground, and through
pull-up or pull-down circuits were connected to the memory controller
logic to tell what size/speed a module was.  They had learned from not
knowing on the 30-pin DIMMs that they needed something, but they also
learned that 4-8 pins of "presence detect" and the associated logic
was too expensive, and so they went to the I2C bus solution.

Oh, I forgot to mention one trick which was done way back when and is
still occasionally done.  Bus transactions generally have the remote
end ACK or NACK the R/W transaction, and some memory controllers and
bus bridges were smart enough to have a timeout which would kick in
after so many ns.  So in the process of your POST, where the firmware
(BIOS) was doing writes to initialize for ECC/parity, this code would
do a trick.  It knew where the ROM was located, and would set a
timeout timer for some value (say 500ns), which was longer than any
memory should take to respond.  Then it would proceed to scan for RAM,
perhaps by doing reads every 64k.  Then having done this, it would
know how much RAM there was, and could go back and do the writes to
initialize for ECC/Parity, then start treating those errors as error
conditions.

> In IXP data sheet memory controller section mentions only one register
> saying size and that is being overwritten by value from bootloader
> (hard coded compile time #define)
> 2 other registes are to talk to / initiate state machine of dram init
> seq, etc ..

You might want to dig through the data sheets and see if that register
is pre-initialized and instead should be read.  Or perhaps you are
dealing with a register where it has a base address and length, and
the memory controller maps the memory bus where you tell it, and the
PCI (or other bus) into another area, etc.  If you want to see how
some of this works, I would suggest looking at the docs for the
MCP-750.  You can find info about it at:

    https://mcg.motorola.com/cfm/templates/product.cfm?PageID=895&ProductID=22&PageTypeID=1

The best doc here would be the MCP750A/PG6, where on page 1-4 (page 30
in the PDF), you will see how these bridges come together, and it will
talk about some of the register settings on the Falcon memory
controller and Raven PCI bridge later in that section.  BTW...on that
doc, the Falcon/Raven combo would essentially be the northbridge of a
x86 machine, and the peripheral bus controller and PCI-to-PCI bridge
would be the southbridge.

> Seem to me a dead wall ahead -;)

No.  Just some work getting the right person to talk to at the
vendors, getting management to get the NDA in place, and then lots of
reading.  I should know, as my group at my employer is doing the same
thing with some Intel HW for a network switch.

- Doug

-- 
Douglas Wade Needham - KA8ZRT        UN*X Consultant & UW/BSD kernel programmer
Email:  cinnion @ ka8zrt . com       http://cinnion.ka8zrt.com
Disclaimer: My opinions are my own.  Since I don't want them, why
            should my employer, or anybody else for that matter! 

Re: Fwd: memory probing

[coly li]

alfred hitch:

It's not so easy to get the proper answer. it depends on your hardware. for I'm not familiar with embedded enviornmnet, I can only give you some idea for x86 platform.

you should know your memory address space layouts. which range is for other peripheral, which range is for real memory. different range use difference detecting scheme. for the range of real memory, the simplest method is "write and verify".

but, for I'm not a embedded programmer, I can't give you more information for non-x86. FYI.
				 
　　　　　　　　coly li
　　　　　　　　colyli@263.net
　　　　　　　　　　2005-05-10


======= 2005-05-10 14:36:51 original messages：=======

>---------- Forwarded message ----------
>From: alfred hitch <alfred.hitch@gmail.com>
>Date: May 10, 2005 2:13 AM
>Subject: Re: memory probing
>To: The development of GRUB 2 <grub-devel@gnu.org>
>
>
>Hi,
>
>thanks for your response,
>actually what I am looking for is that does grub and all use bios
>calls to find out the memory size ?
>on my system there is no bios, ixdp425 based plattform,
>then can I somehow probe amount of memory and not use a #define'ed one ?
>
>Cheers,
>Alfred
>
>On 5/10/05, coly li <colyli@263.net> wrote:
>> alfred hitch:
>>
>> hi! I guess what you want to know more is the initialization for linux kernel.
>> I know a guy who wirtes a perfect text named "i386 linux boot howto", you can find out this text on www.tldp.org.
>> also, I sugest you read the linux boot protocol, you can find this text in linux kenrel source code. maybe the name is boot.txt.
>>
>> good luck;-)
>>
>> coly li
>> colyli@263.net
>> 2005-05-10
>>
>> ======= 2005-05-10 12:08:54 original messages：=======
>>
>> >Hi All,
>> >
>> >I am trying to understand working of bootloaders and have a question
>> >(which might be very elementary perhaps).
>> >
>> >I wanted to understand how does bootloaders probe memory installed on
>> >system and thus pass the correct mem option across to linux kernel
>> >say.
>> >
>> >Can someone please explain if this is dependant on bios necessarilly,
>> >as I am looking for doing something similar on ixdp425 plattform.
>> >
>> >Can u please point me to some relavant doc / code ..
>> >
>> >Cheers,
>> >Alfred
>> >
>> >
>> >_______________________________________________
>> >Grub-devel mailing list
>> >Grub-devel@gnu.org
>> >http://lists.gnu.org/mailman/listinfo/grub-devel
>>
>> = = = = = = = = = = = = = = = = = = = =
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
>>
>>
>
>

= = = = = = = = = = = = = = = = = = = =
	

Re: Fwd: memory probing

[alfred hitch]

thanks,
but what did u mean write and verify, 
I thhot grub depends heavilly on bios calls for all this .. 

Alfred

On 5/10/05, coly li <colyli@263.net> wrote:
> alfred hitch:
> 
> It's not so easy to get the proper answer. it depends on your hardware. for I'm not familiar with embedded enviornmnet, I can only give you some idea for x86 platform.
> 
> you should know your memory address space layouts. which range is for other peripheral, which range is for real memory. different range use difference detecting scheme. for the range of real memory, the simplest method is "write and verify".
> 
> but, for I'm not a embedded programmer, I can't give you more information for non-x86. FYI.
> 
> coly li
> colyli@263.net
> 2005-05-10
> 
> ======= 2005-05-10 14:36:51 original messages：=======
> 
> >---------- Forwarded message ----------
> >From: alfred hitch <alfred.hitch@gmail.com>
> >Date: May 10, 2005 2:13 AM
> >Subject: Re: memory probing
> >To: The development of GRUB 2 <grub-devel@gnu.org>
> >
> >
> >Hi,
> >
> >thanks for your response,
> >actually what I am looking for is that does grub and all use bios
> >calls to find out the memory size ?
> >on my system there is no bios, ixdp425 based plattform,
> >then can I somehow probe amount of memory and not use a #define'ed one ?
> >
> >Cheers,
> >Alfred
> >
> >On 5/10/05, coly li <colyli@263.net> wrote:
> >> alfred hitch:
> >>
> >> hi! I guess what you want to know more is the initialization for linux kernel.
> >> I know a guy who wirtes a perfect text named "i386 linux boot howto", you can find out this text on www.tldp.org.
> >> also, I sugest you read the linux boot protocol, you can find this text in linux kenrel source code. maybe the name is boot.txt.
> >>
> >> good luck;-)
> >>
> >> coly li
> >> colyli@263.net
> >> 2005-05-10
> >>
> >> ======= 2005-05-10 12:08:54 original messages：=======
> >>
> >> >Hi All,
> >> >
> >> >I am trying to understand working of bootloaders and have a question
> >> >(which might be very elementary perhaps).
> >> >
> >> >I wanted to understand how does bootloaders probe memory installed on
> >> >system and thus pass the correct mem option across to linux kernel
> >> >say.
> >> >
> >> >Can someone please explain if this is dependant on bios necessarilly,
> >> >as I am looking for doing something similar on ixdp425 plattform.
> >> >
> >> >Can u please point me to some relavant doc / code ..
> >> >
> >> >Cheers,
> >> >Alfred
> >> >
> >> >
> >> >_______________________________________________
> >> >Grub-devel mailing list
> >> >Grub-devel@gnu.org
> >> >http://lists.gnu.org/mailman/listinfo/grub-devel
> >>
> >> = = = = = = = = = = = = = = = = = = = =
> >>
> >>
> >> _______________________________________________
> >> Grub-devel mailing list
> >> Grub-devel@gnu.org
> >> http://lists.gnu.org/mailman/listinfo/grub-devel
> >>
> >>
> >>
> >
> >
> 
> = = = = = = = = = = = = = = = = = = = =
> 
>