Hi,
On Thu, 23 Sep 1999 [EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] writes:
> > for the different processors we are running. What I'm really doing is
> > changing the memory map setup code so it can figure out it's memory map
> > while it's executing rather than at compile time. This code compiles
> > fine, but the kernel will not run at all. This is the kernel I traced
> > down to not working once the MMU is enabled (i.e. I never make it past
> > the MMU being enabled in head-armv.S).
>
> I've done a major overhaul of the memory initialisation today in 2.3.18,
> so it'll probably knock your changes out.
>
Have you changed it to do what I mentioned above, that is, figure out
it's memory map at runtime vs. compile time? The reason I need this is
because we have 10 different types of memory maps depending on what
processor we are running on, and compilign 10 different kernels is a
pain. Letting the kernel pick this at runtime is nicer in our case.
> It's very unlikely that this is a kernel problem. The kernel memory
> initialisation code works reliably on a lot of NetWinders, RiscPCs,
> EBSA285's and EBSA110's. It's well tested. I'd suggest checking out
> either the way you're calling the kernel, or the hardware itself.
>
> (btw, make sure that the caches are flushed before you enter the kernel
> from your loader. This is an absolute MUST)!
>
Well, thanks for the help Russell. It turns out I wasn't flushing the
caches when I was booting, and this was the actual problem. Once I put
in the proper cache flushing routines, things are working much better
now. Thanks for the help!
--
Kyle Mestery | StorageTek's Storage Networking Group
[EMAIL PROTECTED] | http://www.freebsd.org/
[EMAIL PROTECTED] | http://www.netwinder.org/
Protect your right to privacy: www.freecrypto.org
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
