[parisc-linux] Today's boot experience on a 735
Wed, 17 Nov 1999 21:54:06 +0100
> The problem is the kernel can't determine how big its common data section
> is and therefore where free memory should start.
Okay, I didn't take into account we actually want to know where our free
memory starts - sometimes being stupid doesn't help.
> There are quite a few big structures and arrays throughout the linux code
> that are global and not initiallized.
> Uninitialized common data can be avoided by using static or explicitly
> initializing the data object (puts data into $DATA$ instead of $DLT$).
> Without the trick, _end is located at the end of the
> bss section. When "theend" is linked in, _end moves to the end of
> unitialized common data and the kernel can easily determine where free
> memory starts.
Okay, this is a SOM-specific bug around a missing feature of the SOM linker
(i.e. not supporting linker scripts) (tell me if I'm wrong).
> The current hack to determine the start of free memory is to use a symbol
> that is near the end of the common data and add a fudge amount to it.
> This failed for me recently when I built a configuration without network
> support and the symbol was no longer defined. The size of the common
> data varies depending on kernel configuration as well.
Yeah, this code needs to go / change.
> However, if you explicitly initialize, the size of the kernel will grow.
> I know some systems still allow installation from floppies. The kernel
PARISC systems ?
> Memory from the start of the bss section to the end of the common data
> should be zeroed. I presume other free memory will be initialized when
> it is used.
yup, Linux doesn't need to have all available memory zero'd out on boot.