Re: console colors
Hollis Blanchard <[EMAIL PROTECTED]> writes: > Actually it's funny, I didn't even realize we were using the color > code... because I have seen no colors anywhere. Marco, does that do > anything for you? Colors are supported and used to draw the menu. One of the first things GRUB does is printing an inverted welcome text. I assume this triggers this problem. It seems we need to check if colors are supported or not. Thanks, Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Fwd: memory probing
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 ([EMAIL PROTECTED]): > 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 <[EMAIL PROTECTED]> wrote: > > * alfred hitch <[EMAIL PROTECTED]> [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 - KA8ZRTUN*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
Re: Fwd: memory probing
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 <[EMAIL PROTECTED]> wrote: > * alfred hitch <[EMAIL PROTECTED]> [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
Re: [ppc] [patch] set environment from commandline
On May 10, 2005, at 1:11 PM, Marco Gerards wrote: Hollis Blanchard <[EMAIL PROTECTED]> writes: Also, this patch allows you to boot from the OF commandline, overriding the defaults. Example: boot enet:,grubof prefix=foo; debug=bar This looks like a nice feature to me, especially for development. I wonder what others think of it. Yeah, I consider it absolutely required, so that when users say "it crashed before I could do anything" we can just ask them to boot with "debug=all". Comments? Where is the changelog entry? ;) I was looking for other comments first. I guess you have no problem with it... 2005-05-10 Hollis Blanchard <[EMAIL PROTECTED]> * boot/powerpc/ieee1275/cmain.c (cmain): Remove code to parse /chosen/bootargs. * kern/powerpc/ieee1275/init.c (grub_machine_init): Parse /chosen/bootargs as "variable=value" pairs. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: console colors
On May 10, 2005, at 2:59 PM, Paul Nasrat wrote: Loading ELF method not found; ihandle=ffbc6f80 phandle=ff848300 method not found; ihandle=ffbc6f80 phandle=ff848300 method not found; ihandle=ffbc6f80 phandle=ff848300 method not found; ihandle=ffbc6f80 phandle=ff848300 method not found; ihandle=ffbc6f80 phandle=ff848300 method not found; ihandle=ffbc6f80 phandle=ff848300 method not found; ihandle=ffbc6f80 phandle=ff848300 This could be as the telnet console doesn't support colour. We probably want to be less verbose about this. Agreed. Actually it's funny, I didn't even realize we were using the color code... because I have seen no colors anywhere. Marco, does that do anything for you? -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: non boot-device was Re: [ppc] [patch] set environment from commandline
On May 10, 2005, at 2:59 PM, Paul Nasrat wrote: Ignore the Default catch that seems to be resolved for me. Hmm, if you have any ideas, I'd still like to know how you got that error... Experimental toolchain? -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [ppc] [patch] more cleanups
On May 10, 2005, at 1:01 PM, Marco Gerards wrote: Hollis Blanchard <[EMAIL PROTECTED]> writes: --- include/grub/powerpc/ieee1275/kernel.h 4 Jan 2005 14:01:45 - 1.1 +++ include/grub/powerpc/ieee1275/kernel.h 10 May 2005 01:27:36 - @@ -21,6 +21,6 @@ #define GRUB_KERNEL_MACHINE_HEADER 1 /* Where grub-mkimage places the core modules in memory. */ -#define GRUB_IEEE1275_MODULE_BASE 0x030 +#define GRUB_IEEE1275_MODULE_BASE 0x0030 Huh? Can you explain this? I would even prefer: #define GRUB_IEEE1275_MODULE_BASE 0x30 What is to explain? The address has 7 chars in it when it should have 8. The leading zeroes make it easier to read. Index: loader/powerpc/ieee1275/linux.c [...] - initrd_addr = 0xc000; + initrd_addr = 0; Does loading linux with an initrd still work? I said it did... -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: non boot-device was Re: [ppc] [patch] set environment from commandline
On Tue, 2005-05-10 at 20:16 +0200, Marco Gerards wrote: > Paul Nasrat <[EMAIL PROTECTED]> writes: > > > 0 > boot hd:2,\grubof.modules load-size=2e220 adler32=e04b6e6d > > What are load-size and adler32 used for? Don't you need a `;' here? > > > Loading ELF > > method not found; ihandle=ffbc6f80 phandle=ff848300 method > > not found; ihandle=ffbc6f80 phandle=ff848300 method > > not found; ihandle=ffbc6f80 phandle=ff848300 method not found; > > ihandle=ffbc6f80 phandle=ff848300 method not found; > > ihandle=ffbc6f80 phandle=ff848300 method not found; > > ihandle=ffbc6f80 phandle=ff848300 method not found; > > ihandle=ffbc6f80 phandle=ff848300 > > Welcome to GRUB! > > What kind of box are you using? Which modules are added to > grub.modules? This happens with a working grub from hollis. I guess as I'm using telnet I see it go past: Loading ELF method not found; ihandle=ffbc6f80 phandle=ff848300 method not found; ihandle=ffbc6f80 phandle=ff848300 method not found; ihandle=ffbc6f80 phandle=ff848300 method not found; ihandle=ffbc6f80 phandle=ff848300 method not found; ihandle=ffbc6f80 phandle=ff848300 method not found; ihandle=ffbc6f80 phandle=ff848300 method not found; ihandle=ffbc6f80 phandle=ff848300 This could be as the telnet console doesn't support colour. We probably want to be less verbose about this. Ignore the Default catch that seems to be resolved for me. Paul ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: non boot-device was Re: [ppc] [patch] set environment from commandline
On Tue, 2005-05-10 at 20:16 +0200, Marco Gerards wrote: > Paul Nasrat <[EMAIL PROTECTED]> writes: > > > 0 > boot hd:2,\grubof.modules load-size=2e220 adler32=e04b6e6d > > What are load-size and adler32 used for? Don't you need a `;' here? They were auto added to console by OF - not me. Hold on let me retry with just HEAD as it's broken for me with boot-device now without telnet. It's an imac DV SE. Paul ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: non boot-device was Re: [ppc] [patch] set environment from commandline
Paul Nasrat <[EMAIL PROTECTED]> writes: > 0 > boot hd:2,\grubof.modules load-size=2e220 adler32=e04b6e6d What are load-size and adler32 used for? Don't you need a `;' here? > Loading ELF > method not found; ihandle=ffbc6f80 phandle=ff848300 method > not found; ihandle=ffbc6f80 phandle=ff848300 method > not found; ihandle=ffbc6f80 phandle=ff848300 method not found; > ihandle=ffbc6f80 phandle=ff848300 method not found; > ihandle=ffbc6f80 phandle=ff848300 method not found; > ihandle=ffbc6f80 phandle=ff848300 method not found; > ihandle=ffbc6f80 phandle=ff848300 > Welcome to GRUB! What kind of box are you using? Which modules are added to grub.modules? Thanks, Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [ppc] [patch] set environment from commandline
Hollis Blanchard <[EMAIL PROTECTED]> writes: > We're doing a lot of useless work in cmain(). Agreed. > Also, this patch allows you to boot from the OF commandline, overriding > the defaults. Example: > boot enet:,grubof prefix=foo; debug=bar This looks like a nice feature to me, especially for development. I wonder what others think of it. > Comments? Where is the changelog entry? ;) Thanks, Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
non boot-device was Re: [ppc] [patch] set environment from commandline
On Mon, 2005-05-09 at 00:05 -0500, Hollis Blanchard wrote: > We're doing a lot of useless work in cmain(). > > Also, this patch allows you to boot from the OF commandline, overriding > the defaults. Example: > boot enet:,grubof prefix=foo; debug=bar I thought this might work if I'm using grub with a different boot-device set. Built with cvs and this patch. Setting boot-device and then running boot works Brought to you by " enet:telnet,10.13.0.202" io I love OF packages :) Connected to blueimac.install.boston.redhat.com (10.13.0.202). Escape character is '^]'. ok 0 > printenv boot-device -- Partition: common Signature: 0x70 --- boot-device /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]:2,\ \:tbxi hd:,\\:tbxi ok 0 > dir hd:2,\ bootstrap 115 4/23/57 8:10:55 grub.cfg 188960 5/11/ 5 4:52: 4 grubof.modules 3191 5/11/ 5 2:23:43 ofboot.b 141492 5/11/ 5 2:23:43 yaboot 638 5/11/ 5 2:23:43 yaboot.conf ok 0 > boot hd:2,\grubof.modules load-size=2e220 adler32=e04b6e6d Loading ELF method not found; ihandle=ffbc6f80 phandle=ff848300 method not found; ihandle=ffbc6f80 phandle=ff848300 method not found; ihandle=ffbc6f80 phandle=ff848300 method not found; ihandle=ffbc6f80 phandle=ff848300 method not found; ihandle=ffbc6f80 phandle=ff848300 method not found; ihandle=ffbc6f80 phandle=ff848300 method not found; ihandle=ffbc6f80 phandle=ff848300 Welcome to GRUB! DEFAULT CATCH!, code=300 at %SRR0: 001f9dac %SRR1: 3030 ok 0 > .registers Client's Fix Pt Regs: 00 7c7d1b78 0032af30 fff2 001f2340 001f21f0 2d3c2808 08 0002 7c7d1b78 001fefc0 001f21f5 10 18 001f2358 001f2348 0003 001f2790 001f2340 001f396c 001f2210 Special Regs: %IV: 0300 %SRR0: 001f9dac %SRR1: 3030 %CR: 4282 %LR: 001f9db4%CTR: 00208644%XER: %DAR: 7c7d1b78 %DSISR: 4000 %SDR1: 07fe ok 0 > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [ppc] [patch] more cleanups
Hollis Blanchard <[EMAIL PROTECTED]> writes: > I've found a few more things that needed cleaning, so here is the > updated patch. I have tested it. It looks fine to me. I have a few questions: > (grub_ieee1275_next_property): Likewise. Change type of first argument > to grub_ieee1275_phandle_t. Please use double spaces. > --- include/grub/powerpc/ieee1275/kernel.h4 Jan 2005 14:01:45 - > 1.1 > +++ include/grub/powerpc/ieee1275/kernel.h10 May 2005 01:27:36 - > @@ -21,6 +21,6 @@ > #define GRUB_KERNEL_MACHINE_HEADER 1 > > /* Where grub-mkimage places the core modules in memory. */ > -#define GRUB_IEEE1275_MODULE_BASE 0x030 > +#define GRUB_IEEE1275_MODULE_BASE 0x0030 Huh? Can you explain this? I would even prefer: #define GRUB_IEEE1275_MODULE_BASE 0x30 > Index: loader/powerpc/ieee1275/linux.c [...] > - initrd_addr = 0xc000; > + initrd_addr = 0; Does loading linux with an initrd still work? Thanks, Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: PPC executable name
Hollis Blanchard <[EMAIL PROTECTED]> writes: > I'd like to rename the PPC executable from "grubof" to "grub". If > nothing else, it will avoid the question "is it grubof.cfg or > grub.cfg?". Thoughts? What I would prefer is _grub or so. To make clear it is not usable just like this. We don't want people loading this file directly. Adding a "_" might make it clear this is a file that is weird in a way and users should not use it directly. The name `grubof' is not *that* bad either. People do not use it directly, right? For any arch the config file should be called grub.cfg, IMO. Thanks, Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: PPC executable name
Hollis Blanchard [Sun, May 08, 2005 at 10:02:06PM -0500]: > I'd like to rename the PPC executable from "grubof" to "grub". If > nothing else, it will avoid the question "is it grubof.cfg or > grub.cfg?". Thoughts? grub.cfg, as a user I am not interesed it "oh there is openfirmware", but I simply assume: config = packagename.cfg and if I know grub(x86) I assume grub(ppc) and grub(sparc) use the same config with similar syntax. Nico pgpsXnY0y4ZQW.pgp Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Fwd: memory probing
* alfred hitch <[EMAIL PROTECTED]> [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
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 <[EMAIL PROTECTED]> wrote: > "coly li" <[EMAIL PROTECTED]> 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 > > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Fwd: memory probing
"coly li" <[EMAIL PROTECTED]> 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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Re: Fwd: memory probing
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 [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 >> [EMAIL PROTECTED] >> 2005-05-10 >> >> === 2005-05-10 14:36:51 original messages：=== >> >> >-- Forwarded message -- >> >From: alfred hitch <[EMAIL PROTECTED]> >> >Date: May 10, 2005 2:13 AM >> >Subject: Re: memory probing >> >To: The development of GRUB 2 >> > >> > >> >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 <[EMAIL PROTECTED]> 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 >> >> [EMAIL PROTECTED] >> >> 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 >> >> >> >> >> >> >> > >> > >> >> = = = = = = = = = = = = = = = = = = = = >> >> = = = = = = = = = = = = = = = = = = = = ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Fwd: memory probing
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 <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > 2005-05-10 > > === 2005-05-10 14:36:51 original messages：=== > > >-- Forwarded message -- > >From: alfred hitch <[EMAIL PROTECTED]> > >Date: May 10, 2005 2:13 AM > >Subject: Re: memory probing > >To: The development of GRUB 2 > > > > > >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 <[EMAIL PROTECTED]> 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 > >> [EMAIL PROTECTED] > >> 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 > >> > >> > >> > > > > > > = = = = = = = = = = = = = = = = = = = = > > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Fwd: memory probing
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 [EMAIL PROTECTED] 2005-05-10 === 2005-05-10 14:36:51 original messages：=== >-- Forwarded message -- >From: alfred hitch <[EMAIL PROTECTED]> >Date: May 10, 2005 2:13 AM >Subject: Re: memory probing >To: The development of GRUB 2 > > >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 <[EMAIL PROTECTED]> 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 >> [EMAIL PROTECTED] >> 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 >> >> >> > > = = = = = = = = = = = = = = = = = = = = ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
