[parisc-linux] Today's boot experience on a 735

[Philipp Rumpf]

> 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.

	Philipp Rumpf