linux-mips-fnet
[Top] [All Lists]

Re: Non-verbose boot?

To: linux-mips@fnet.fr
Subject: Re: Non-verbose boot?
From: Stoned Elipot <Stoned.Elipot@univ-evry.fr>
Date: Mon, 4 Sep 1995 13:49:53 +0200
In-reply-to: <199509040556.HAA02096@newton.waldorf-gmbh.de> (message from Andreas Busse on Mon, 4 Sep 1995 07:56:26 +0200)
Reply-to: Stoned.Elipot@univ-evry.fr
>>>>> "Andreas" == Andreas Busse <andy@waldorf-gmbh.de> writes:
[SNIP]
Andreas> Yes, I am! I was also thinking about printing a dot for each
Andreas> sector, but now that you've done that already... :-) Send me
Andreas> the patches, and I'll integrate them into the current
Andreas> version. Stoned, any other patches from you ?

Not yet, go ahead if you wnt to release a new milo, I'm working on
Oily RAM detection, and thinking hard about the NAPS (new argument
passing scheme, I like this expression :) between Milo/Kernel.

BTW Ralf, we should read the tags list in setup_arch() just as
bootinfo struct's infos are used in currents kernel version, right ?
So What to do if we have larger stuff to extract from the tags list
(aka G364 font table :)?  My problem is that I can't see
where to put this table: I don't want to waste the memory used by the
tag list, so I should made this piece of RAM availble for the
_init(start_mem, end_mem) routines calls in main.c. But the font table
this quite "huge", so what if we tune the creation of tags list by
Milo, in order to have such big item, one after another, at the very
beginning of the list. Something like: 


--------+---------+-----+ ...        --+-----------
kernel  | ramdisk | font|              | available mem
        |         |     |              |
        |         |     |              | 
--------+---------+-----+- ...        -+-----------
                  |     |              |
                  |<- whole tag list ->|
                  |<- ->|
                   This remains in place
                        |<- This is  ->|
                            available as free mem after setup_arch()

This way, the font - or other stuff we don't yet know about :) - it at
a well defined place, and only few octets are wasted (the tag header
of the font). Comments ?

Cheers, Stoned.

<Prev in Thread] Current Thread [Next in Thread>