GENERIC kernel issues

[Aleksandr Rybalko]

On Wed, 6 Mar 2013 12:33:11 -0700
Warner Losh <imp at bsdimp.com> wrote:

> 
> On Mar 6, 2013, at 11:32 AM, Ian Lepore wrote:
> 
> > On Wed, 2013-03-06 at 10:03 -0700, Warner Losh wrote:
> >> On Mar 5, 2013, at 8:58 PM, Ian Lepore wrote:
> > [...]
> >>> We essentially pull off the same mapping trick with the kernel,
> >>> except that very early in locore.s the code is carefully crafted
> >>> to work right whether on physical or virtual addressing, just
> >>> long enough to get the MMU turned off.  Then it sets up page
> >>> tables to map the physical pages the kernel has been loaded into
> >>> to match the virtual addresses it was linked for.  All of that
> >>> only works if the low-order bits of the virtual address it was
> >>> linked for match the physical address it was loaded at. That is,
> >>> if linked for 0xC0001000 it must be loaded at 0xNNNN1000
> >>> physical, where the N bits can be anything.
> >> 
> >> Right, but can't we get that from the virtual address.
> > 
> > Not always.  You can always figure out the right virtual address if
> > you have the physical (you just OR-in 0xC0000000), but you can't
> > always go the other way.  If all you know is 0xC0010000 you have no
> > idea whether the underlying physical address might be 0x00010000 or
> > 0x80010000.  Our current code that assumes you can do
> > phys=pc&0xf0000000 is wrong for the same reason (but has been
> > working okay by accident).
> 
> The phys segment is pc & 0xf0000000 before you turn on the MMU
> (assuming 256MB chip select offsets, adding another F would get that
> down to 16MB chip selects, which is definitely good enough). After we
> MMU start, it isn't, and our code shouldn't do that, unless it is
> followed by oring in the physical segment...
> 
> > That's part of why I've been working towards getting our arm
> > ldscript to put proper physical addresses in the elf headers
> > instead of virtual, in the fields that are supposed to have
> > phsyical addresses in them (entry and program-header paddr fields).
> 
> But that doesn't matter for the kernel so much...
> 
> > With this scheme SoC-specific kernels will be linked with PHYSADDR=
> > the real physical address and can be loaded by any standard elf
> > loader because the headers are correct.  A generic kernel will be
> > linked with PHYSADDR=offset where offset is just the low-order part
> > of the address and ubldr can load the kernel into whatever physical
> > memory is available as long as the offset part stays the same.
> 
> OK. That part makes perfect sense now.
> 
> Warner
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"

Maybe we should just let ubldr to enable MMU for us? Like we do for
i386, IIRC.

WBW
-- 
Aleksandr Rybalko <ray at freebsd.org>