[syslinux] Re: Problem with FreeDOS + himem64 + PXELINUX + memdisk

[Dag Wieers]

On Tue, 27 Jan 2004, H. Peter Anvin wrote:

> Dag Wieers wrote:
> > 
> > Hmmm, it would be nice if it would say the types instead of the type-code.
> > Maybe even indicate what the normal usage of some segments are (if they 
> > are known) and the length in bytes. Would it be possible to do 
> > something like this for output:
> > 
> > 	Ramdisk at 0xfe60000, length 1474560 bytes
> > 	e820:   0x100000: 267321344 bytes (memory)
> > 	e820:  0xfff0000: 60416 bytes (acpi0)
> > 	e820:  0xfffec00: 5120 bytes (acpi1)
> > 	e820: 0xfff80000: 524288 bytes (reserved)
> > 
> > This email was very informative I wonder whether it is possible to explain 
> > the memdisk output a bit more in the documentation ? And if the output is 
> > a bit more sensible for ignorant people like me it even wouldn't have to 
> > be documented ;)
> 
> Quite frankly, if you can't tell just by looking at it what it is you 
> clearly don't know how the e820 memory map works, and should be looking 
> up its documentation.

I did say I was ignorant, did I ? Still, the type/type-code suggestion is 
valid. It's done in the kernel too:

	BIOS-provided physical RAM map:
	 BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
	 BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
	 BIOS-e820: 00000000000d2000 - 00000000000d4000 (reserved)
	 BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
	 BIOS-e820: 0000000000100000 - 000000001ff70000 (usable)
	 BIOS-e820: 000000001ff70000 - 000000001ff7e000 (ACPI data)
	 BIOS-e820: 000000001ff7e000 - 000000001ff80000 (ACPI NVS)
	 BIOS-e820: 000000001ff80000 - 0000000020000000 (reserved)
	 BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved)

It doesn't say how large each block is. But if you say the size of each 
region is irrelevant, who am I to argue with you.

This is the output from memdisk, first row is location, second is size:

        e820: 0000000000000000 000000000009f000 1
        e820: 000000000009f000 0000000000010000 2
        e820: 00000000000d2000 0000000000020000 2
        e820: 00000000000dc000 0000000000240000 2
        e820: 0000000000100000 00000001fe600000 1
        e820: 000000001ff60000 00000000001a0000 3
        e820: 000000001ff7a000 0000000000020000 4
        e820: 000000001ff7c000 0000000000040000 2
        e820: 000000001ff80000 0000000000800000 2
        e820: 00000000ff800000 0000000000400000 2
        e820: 00000000ffc00000 0000000000400000 2

And maybe this is what I'd be more comfortable with, and you are clearly 
heavily against. (PS the previous example had some miscalculations)

	e820: 0000000000000000 -> 000000000009f000  636kB (usable)
	e820: 000000000009f000 -> 00000000000a0000   64kB (reserved)
	e820: 00000000000d2000 -> 00000000000d4000  128kB (reserved)
	e820: 00000000000dc000 -> 0000000000100000   34kB (reserved)
	e820: 0000000000100000 -> 000000001ff70000  510MB (usable)    
	e820: 000000001ff70000 -> 000000001ff7e000    1MB (ACPI data)   
	e820: 000000001ff7e000 -> 000000001ff80000  128MB (ACPI NVS)  
	e820: 000000001ff80000 -> 0000000020000000    8MB (reserved)    
	e820: 00000000ff800000 -> 0000000100000000    8MB (reserved)

Why the Linux kernel joins some of the regions, I don't know.
But I wouldn't mind the display is 80x25 and you don't have a 
buffer to scroll.


> Suggesting mixing hex and decimal is beyond ridiculous.

Displaying quantities in hex seems beyond reasonable to me.

There are other examples that, at least for displaying quantities, they 
use decimal notation.

	[root at lisse root]# cat /proc/mtrr 
	reg00: base=0x00000000 (   0MB), size= 256MB: write-back, count=1
	reg03: base=0xd8000000 (3456MB), size=   8MB: write-combining, count=1

Although you still have to provide it using eg.:

	echo "base=0xe2000000 size=0x2000000 type=write-combining" >| /proc/mtrr

Just a suggestion, since I can't code. No real reason to listen or even to 
fear a fork ;)))

And I'm only suggesting it because this thread was about Patrick 
mis-interpreting the output.

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]