GENERIC kernel issues

[Aleksandr Rybalko]

On Wed, 6 Mar 2013 14:57:56 -0700
Warner Losh <imp at bsdimp.com> wrote:

> 
> On Mar 6, 2013, at 2:40 PM, Aleksandr Rybalko wrote:
> 
> > 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.
> 
> One weak reason is that uboot and other loaders that are used to
> loading Linux are forbidden from having the MMU enabled when they
> transfer control to the kernel they boot. We'd want to still work
> there, and would need extra/different code to cope with the booted
> with the MMU enabled and booted without the MMU enabled.
> 
> Warner
> 

IIRC, there was already decided point, to have one kernel per
incompatible device and single kernel for all systems that we can make
generic. Right?
ubldr depend on U-Boot, and U-Boot must be recompilled with CONFIG_API
thing, which is not enabled in all uboots I ever seen. So in that case
we can even make ubldr compiled into uboot as uboot-app :)
So we need to decide where we will do ugly things:
1. in U-Boot (or other loader)
2. in ubldr
3. in kernel
in some case we can't replace original loader and/or add second loader
(second uboot), and we prefer to have most of thing to looks identical
in kernel. So my finger points on ubldr. And it will be nice to teach
ubldr to work with other loaders and somehow not to depend on
CONFIG_API of uboot.

Thanks!

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