Not always. Keep in mind we have several machine types that follow the
same patch there. We don't always enter with OF and OF doesn't always give
1:1 mappings, either.
} The kernel enters from OF, with the MMU in whatever state OF set it and
} the guarantee that at least it's mapped 1:1 with some memory (1Mb) also
} mapped just after it so that it can expand itself. This guarantees are
} the responsibility of the bootloader.
I don't care for it much but it gives us a foothold and OF doesn't seem to
use bat1 ever...
} At this point, it hacks a BAT to map the first 16Mb of memory to
} KERNELBASE. That I don't like since it means playing with mapping of
} potentially running code with MMU enabled (and you don't know if OF
} didn't use a BAT itself for mappping the RAM you are running from, future
Not dependent on the bootloader, just dependent on the current running
address and whether MSR_DR is set in the MSR or not.
} OF versions may do). It will then do all sort of weird guesses depending
} on the bootloader to know if it must translate or not the source address,
} do the copy and flush (which will usually default catch to OF with my
} bootloader, depending on where I loaded the kernel, etc...)
at 0x10000 on chrp when running quik.
} Quik tries to load the kernel at 0, which avoids most of those head.S
} issues, but the way it does is broken, since OF won't allow to CLAIM
} memory from 0 (at least not on my machine), that means potentially
} overriding bits of OF (I know OF tends to use high memory, but OF low
} memory vectors are still needed, at least on 603 for prom_entry to work).
We only do that after we've called prom_entry() for the last time, though.
} Also, the bootloader can't turn MMU off and clean TLB & BATs since
} prom_entry must have the correct OF mappings in order to work.
}
} Instead of trying to find out the magical address to load the kernel,
} potentially breaking with future OF versions, and hacks like that, I
} finally decided to give a try at fixing head.S (I'm still using 2.2.x
} kernels, I beleive head.S did change with 2.3.x, I'll look into this later).
}
} Basically, what I'm doing is, after bl prom_entry, and before filling the
} BAT, I turn the MMU off, clear all bats (in a 601-compatible way unlike
} the current kernel source tree), flush TLBs, and then continue to the
} code that sets up the BAT and moves down the kernel to 0. I also had to
} comment out the code that translates the source address on CHRP.
That's a good way to do it but shutting it down isn't always that easy. On
some PReP's (the IBM 830 I think) we come into the kernel with MSR_IR on
and MSR_DR off and we're running with some odd I mappings (not D mappings, though).
} I'll post a patch later today, but I wanted to know if my way of doing
} things is broken or will break CHRP machines or not. Basically, I feel
} the "good way" is to shut down the MMU upon exit from prom_entry, and
} then play with BATs, copy&flush, etc...
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Christian Zankel <hidden> Date: 1999-11-22 23:17:44
Hi,
It seems to me that on almost every machine linuxppc is running on
depends on having a bootloader to load the kernel. Would it be possible
to redesign all bootloaders to load the kernel to position 0, initialize
the OF path where necessary and jump to the kernel with the MMU switched
off? Then we could possibly remove all the conditional code (#if ...
#else .. #endif) in head.S mm/init.c, etc.
Right now, it is painfull to add a new machine that doesn't follow the
full PReP,CHRP specification, i.e. has no OF nor Residual Data
structures, etc.
I started to restructure the arch/ppc tree. However, I would like to
hear about your thoughts and recommendation. The goals I want to
achieve, are:
1. The bootloader gets a more active part, i.e. does some
pre-initiaization, esp. to get rid of the 'bl prom_init' and the variaty
of copying the kernel back and forth.
2. It should be possible to setup the kernel so that the same kernel
runs on all those machine that it is setup for. Of course, the more
machines you add the more overhead you get.
3. Each machine/architecture should get its own directory (pmac, prep,
chrp, apus, geminit, etc.)
4. To add a new machine, only a new directory has to be added and only a
few files have to be changed (mainly: Config.in and Makefile).
5. The _machine-ID is seperated into to fields, Vendor and Board.
Thanks,
Christian
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 1999-11-23 10:35:04
On Mon, Nov 22, 1999, Cort Dougan [off-list ref] wrote:
CC: linuxppc-dev@lists.linuxppc.org, linuxppc-dev@lists.linuxppc.org
----------
Not always. Keep in mind we have several machine types that follow the
same patch there. We don't always enter with OF and OF doesn't always give
1:1 mappings, either.
Yes, I agree. but I beleive the piece of bootloader appended to the head
of the kernel image or the early bootloader used (quik ?) should take
care of those very weird case and of mapping the kernel 1:1 before
entering it.
} The kernel enters from OF, with the MMU in whatever state OF set it and
} the guarantee that at least it's mapped 1:1 with some memory (1Mb) also
} mapped just after it so that it can expand itself. This guarantees are
} the responsibility of the bootloader.
I don't care for it much but it gives us a foothold and OF doesn't seem to
use bat1 ever...
There is no guarantee. I'll check what OF does on my machine, but I
really sounds risky to assume that. I did experience _lots_ of weird
crashes during boot and kernel relocation until I added the code to turn
the MMU off. Also, the range mapped with this BAT may overlap with
whatever OF has mapped previously.
The 1:1 mapping requirement I wrote about is just to make sure we get the
correct physical address when turning the MMU off. This could eventually
be replaced by a real boot params structure in one register (r3 ?) and
the kernel's entry physical address in another (r4 ?). Basically, if we
don't require 1:1 mapping, then we need to be given our own physical
address. I really don't like the idea of playing with this BAT with MMU
ON, and as I wrote you, I did experience various bad behaviour. Also, I
can't turn MMU off from the bootloader since the prom_init stuff needs
the MMU to be kept in it's original OF setup until we finish initialising.
Not dependent on the bootloader, just dependent on the current running
address and whether MSR_DR is set in the MSR or not.
You are right, but there is this CHRP address translation I didn't fully
catch.
at 0x10000 on chrp when running quik.
Isn't there a risk here in the copy&flush code ? When copying the kernel
down, won't the copy&flush code override itself ? (We are lucky, it's in
the cache... but we have no guarantee neither that the cache is enabled
at this point).
We only do that after we've called prom_entry() for the last time, though.
Hum... quik loads the kernel at 0, which _will_ override whatever vectors
where here way before we stop using OF. I think most OF implementations
use ROM based vectors at FFxxxxxx but this is still, I think, a dangerous
assumption. On the iBook, OF won't let you claim a range of memory
including the low mem vectors.
That's a good way to do it but shutting it down isn't always that easy. On
some PReP's (the IBM 830 I think) we come into the kernel with MSR_IR on
and MSR_DR off and we're running with some odd I mappings (not D mappings,
though).
Ouch. I think this should be taken care by the small bootstrap appended
to the kernel (but that's only my opinion). In any way, if we could at
least differenciate those case clearly (let's say with some kind of
explicit machine number in a register on the kernel entry, not a
structure since at this point we don't want to access memory at all I
beleive).
Will those machine boot from OF ? I mean, is it OF who is setting up this
weird mapping ? In this case, wouldn't it be possible to fix this from
the bootloader using the OF "map" method ? If it's not OF, then I could
be fixed from the head bootloader.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Mon, Nov 22, 1999, Cort Dougan [off-list ref] wrote:
quoted
CC: linuxppc-dev@lists.linuxppc.org, linuxppc-dev@lists.linuxppc.org
----------
Not always. Keep in mind we have several machine types that follow the
same patch there. We don't always enter with OF and OF doesn't always give
1:1 mappings, either.
Yes, I agree. but I beleive the piece of bootloader appended to the head
of the kernel image or the early bootloader used (quik ?) should take
care of those very weird case and of mapping the kernel 1:1 before
entering it.
Please, excuse my ignorance, but why not just set real-mode OF variable
to true (maybe in the ELF .note section) ?
Regards,
-velco
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden> Date: 1999-11-23 16:15:21
On Mon, 22 Nov 1999, Christian Zankel wrote:
Hi,
It seems to me that on almost every machine linuxppc is running on
depends on having a bootloader to load the kernel. Would it be possible
to redesign all bootloaders to load the kernel to position 0, initialize
the OF path where necessary and jump to the kernel with the MMU switched
off? Then we could possibly remove all the conditional code (#if ...
#else .. #endif) in head.S mm/init.c, etc.
Right now, it is painfull to add a new machine that doesn't follow the
full PReP,CHRP specification, i.e. has no OF nor Residual Data
structures, etc.
If you are able find a single machine which correctly follows the specs...
I started to restructure the arch/ppc tree. However, I would like to
Good luck, I would like to do this too. Note that I haave specific code
for MVME boards which is fairly clean (but nobody seems interested). It
requires residual data for now, if only I could get my hands on a machine
with an OF which at least gets configuratioon space device numbers
right...
hear about your thoughts and recommendation. The goals I want to
achieve, are:
1. The bootloader gets a more active part, i.e. does some
pre-initiaization, esp. to get rid of the 'bl prom_init' and the variaty
of copying the kernel back and forth.
Mine does a lot of this things for machine with residual data: it has its
own simple memory management and a few other things:
- the braindead PCI I/O space allocation on PreP is completely redone
(current kernel PreP code can cause collisions).
- an x86 emulator for ROM BIOSes
2. It should be possible to setup the kernel so that the same kernel
runs on all those machine that it is setup for. Of course, the more
machines you add the more overhead you get.
I don't care very much for 6xx/7xx machines... Embedded may want the
smallest footprint however. My bootloader is already something like 50kb
of code (ok, including the emulator), and I try to fight bloat...
3. Each machine/architecture should get its own directory (pmac, prep,
chrp, apus, geminit, etc.)
Not exactly, rather a boot directory IMHO so that you find the right image
in the right place.... But then pmacs have several image formats depending
on their age...
4. To add a new machine, only a new directory has to be added and only a
few files have to be changed (mainly: Config.in and Makefile).
5. The _machine-ID is seperated into to fields, Vendor and Board.
Maybe... But also all the PCI resource management has to be cleaned up at
least for PreP...
Gabriel.
P.S: my bootloader is available on vlab1.iram.es:/pub/linux-2.2, I'm
trying to boot 2.3.28 now...
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/