mm/init.c

[Francois-Rene Rideau]

On Sun, May 02, 2004 at 07:07:46PM +0200, Oleg Gusev wrote:
>> 	reserve_bootmem_node(pgdat, PHYS_OFFSET, (1024+384)*1024); // oleg way
> Exactly! And it doesn't work.
Hum. Wierd. I'll try that at home...

BTW, it seems to me that the latest CVS crashes after mounting /dev.
I happily saved my working setup just before I updated from CVS, and it's in
	http://jornada820.sourceforge.net/fare/j820

Dave: BTW, your hpcbootm.exe on sf.net ought to be a hardlink to oleg's;
and maybe we should remove obsolete files.

> The real linux bootloader should start,
> find out where it is put by wince in the memory,
This doesn't matter much: all code is PC-relative,
and the arch/arm/boot/compressed/ code handles relocation
of the zImage and uncompressed kernel.
All that matters is that we arrange for the zImage, zbss, kernel,
ununinitialized mmaped I/O zones, kernel parameter zone and initrd
to be at disjoint places.

> reset the memory division into program/data sections,
> grab all available memory,
I don't understand what you mean there;
do you envision some kind of hpcboot rewrite that runs native under WinCE ?
All that's missing from hpcboot is a kernel command line text box
(which would require a slight change in our head.S).
Why do you feel the need for something more substantive?
Or do you want something like blob, except with native console support,
and CF and filesystem support for loading, and maybe network support too?

If you want to do a lot of hacking, here's one project I propose:
what we really need is a kernel hook for loading and booting a new bootimage.
Thus we could load our CVS bootimage with the usual hpcbootm
(or a reduced version), and linux itself may serve as an advanced bootloader.
I'm sure that LinuxBIOS people have patches for that on i386;
maybe they could be ported to ARM in a straightforward way.
Additional gain, this way, we could eventually have a "WinCE" image
to restart WinCE from Linux (yay!)

> reset sa1101, stop busmaster dma,
That we could do in our j820/head.S; shouldn't we?

> probably relocate itself to the top of the memory,
Not necessarily. It could be location-independent.
Or load low enough so as to be able to load the kernel high.

> probably disable the framebuffer and setup the kernel command
> line with the additional brightness/contrast/sound level/day/year parameters.
Yes, that'd be great.

> Then wince will be really wiped out, and the kernel can be put
> even at 0xc0000000. But this is the ideal setup.
Frankly, what's wrong with a kernel at 0xc0200000 ???

> PS. You can try a really funny thing: try to put the kernel
>         at 0xd0000000 ! I'm wondering how many kernel
>         bugs you will hit :-).
I'll try when I have time.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
Lorsqu'on veut accomplir quelque belle action, il faut la faire
et oublier les peines qu'elle peut entrainer.
	-- Mo-Tse