PHYSADDR

[Tim Kientzle]

On Feb 28, 2013, at 8:20 AM, Ian Lepore wrote:

> On Wed, 2013-02-27 at 22:27 -0800, Tim Kientzle wrote:
>> Starting to look at what is needed for a Generic ARM kernel.
>> There's a lot here; I sincerely hope I'm not the only one… ;-)
>> 
>> First up:  Can we get rid of PHYSADDR?
>> 
> 
> If you mean, can we get rid of it within the runtime kernel, I'd say
> yes, because we can use a global variable instead which is easily
> settable in the entry code.

It doesn't seem to be used in the runtime kernel.  As far as
I can see, it's purely a bootstrap concept.

>  On the other hand, I've been working
> towards getting that value set correctly in the kernel elf headers at
> link time.

My question really boils down to whether PIC techniques
are sufficient for the early bootstrap stage to determine
where the kernel is currently executing and use that to
drive the initial MMU bring up.  I've just started, but
the PHYSADDR uses I've examined can be replaced
with PIC techniques.  But this part of the code is
pretty involved and riddled with conditional compilations,
so it will be slow going.

I was impressed to find that ubldr seems to be PIC.
I've run the same binary at different load addresses
and so far it "just works."  (I didn't think it would work,
so I was surprised by this.  I haven't dug through to
figure out why it works yet.)

> Where to physically load the kernel has to be specified somewhere.

Yes, in the loader.  Once the kernel is running, it can look
at the PC and see where it was loaded.  I'm doubtless
oversimplifying, though. ;-)

> So how would something like ubldr decide on a physical load address for
> a generic kernel that had, say, zeroes in the paddr and e_entry fields?

I'm not sure yet.

> The trampoline code replicates the "loader has empirical knowledge"
> problem, because it is in effect another loader.  The address at which
> the external loader loads the kernel.gz.tramp has nothing to do with the
> address at which the trampoline places the decompressed kernel.  Right
> now it's another case of the loader (trampoline) bit-twiddling the
> virtual addresses from the kernel's elf headers.

I'm focusing on the non-trampoline case first.  I agree that the
trampoline is trickier.

> I'm not sure we can completely wish away the trampoline, but I think we
> can define some conventions that ensure its existance is not a barrier
> to having a generic kernel, pretty much just by saying so.  For example,
> we could require that a kernel have valid physical addresses in the elf
> headers for the trampoline to operate on, and simply state that generic
> kernels designed to be loaded anywhere can't use the trampoline.

I would be happy with this if we can't do any better.

> I had to put some effort recently into figuring out some of the perverse
> details of how an at91 SoC gets from first-electrons to a running
> kernel, and I took notes at the time.  I started formatting the notes
> into a wiki page, but only got the first half of them cleaned up.
> Still, there may be some useful info even if the formatting is rough:
> 
> https://wiki.freebsd.org/FreeBSD/arm/BootProcess

Thanks, I'll take a careful look at this.

I have a lot of notes about the BeagleBone and RPi boot
processes as well.

Tim