On 05.06.2009 17:09, Myles Watson wrote: >>> I'm not sure it gets any easier to understand or less cryptic by calling >>> the amount of RAM end of RAM and printing it twice? >>> >>> >> Actually, it's the end of RAM. On my 4 GB machine, tom_k is 0x00500000 >> which is 5*1024*1024. The hole starts at 3 GB in that configuration. >> However, printing it twice serves no purpose. I'll fix and resend. >>
Turns out it once prints the unadjusted RAM end and once the adjusted RAM end, so killing off either of the prinks is not advisable. > I think it makes it easier to review patches like this (that only > change debugging output) if you include before and after log snippets. > Old messages for my machine with 5 GB: RAM: 0x00400000 kB Ram3 [...] Initializing memory: done RAM: 0x00500000 kB New messages: RAM end at 0x00400000 kB, hole starts at 0x00000000 kB Adjusting lower RAM end Lower RAM end at 0x003f0000 kB Ram3 [...] Initializing memory: done Handling memory hole at 0x00300000 (default) RAM end at 0x00500000 kB, hole starts at 0x00300000 kB Handling memory mapped above 4 GB Upper RAM end at 0x00500000 kB Correcting memory amount mapped below 4 GB Adjusting lower RAM end Lower RAM end at 0x00300000 kB I hope this helps understand my patch better. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
