"Yoshinori K. Okuji" <[EMAIL PROTECTED]> wrote:
> > -- Testing for some things, including >4GB machines (I have one > > now). > > I think GRUB should work. IIRC, there were some successful reports on > large memory machines several months ago. Yeah. I reviewed some of the code this weekend for various possible sanity checks, and everything I could think of looks ok. Plus, I tried it on my brand-spanking new 6GB machine, and it works great. The way Linux handles the "mem=" option on it's command line with respect to disjoint memory regions dovetails very nicely with how GRUB passes it. Their scheme is natural enough it even makes me tempted to recommend changing the Multiboot format to remove the BIOS memory map and instead pass the memory map on the command line, since in general text/human- readable information is easier to work with, and I don't think it would be harder than the memory map interpreter that people already have to write into their kernels. Oh well, that and maybe other Multiboot info bits being passed as text/human-readable is food for thought. I've been getting more opinionated about such things as I go further into working on my own OS project. I'm kind of imagining going back to an ultra-simple MB info block with just lower/upper memory (i.e. the info you need RIGHT AWAY before you can even, say, allocate a stack), then a bunch of text bits that are optional. The VERY cool thing about the extra bits being text is that, done right, a human could override/rewrite those bits if desired, OR they could be added by a human while using a bootloader that doesn't support those fields. So, you can smoothly use new fields in newer OSes while an older bootloader doesn't support them. Cool, eh? I would like to discuss this idea further in the context of looking at Multiboot ver 0.7. I'm in the process of reviewing it. One minor/somewhat cosmetic issue in GRUB, when displaying the memory information from the map (my old "displaymem" command), it displays lengths in decimal, which is kind of crude and hard to interpret. I feel tempted to switch it to hex, especially after trying it out and finding it much easier to interpret. Would you or anyone else you know of care? > > -- Do Linux boot support for SETUP code version 2.02 (I think > > that's the version at least). Maybe someone has done > > this already (haven't checked the CVS archive in the last > > month or so...)? > > Do you mean supporting the new feature in 2.02 (i.e. putting a > command-line arbitrarily)? For now, GRUB doesn't use this feature in a > useful way, but just sets the command line pointer to the (old) fixed > place. Yes. There are some very specialized boards/machines that don't work because they have abnormally large EBDA areas, and I have an itch to make even those work. -- Erich Stefan Boleyn <[EMAIL PROTECTED]> http://www.uruk.org/ "Reality is truly stranger than fiction; Probably why fiction is so popular" _______________________________________________ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub