On Thu, Nov 16, 2006 at 04:29:51PM -0500, Roland Roehrich wrote:
Hi Roland,
I know little about PPC architecture and all my discussion henceforth
is based upon logical extension of i386 and x86_64 arch.
FYI, I don't think somebody has actively tested and maintained
the PPC code for kexec/kdump. Currently only a framework is out there
which might require bug fixing to make it work for the various PPC
platforms/sub-architectures.
>
> Yes, I am worried about the relocate_kernel.S. relocate_kernel.S has/does:
> 1) a fixed interface for each architecture, ppc and i386 are different.
> 2) Turn off MMU & use identity mapped page
Once you turned off the MMU, pagining is not used at all hence no need
of identity mapped page?
> 3) relocates the destination kernel, as needed.
> 4) sets up a fixed interface
> 5) jumps to start_address (r5)
>
> I changed my relocate_kernel.S to add a TLB 1-to-1 mapping of DRAM (very
> architecture specific), so that 1) the first context switch (rfi) works,
> and 2) a jump to any other page in memory is possible. Notice that
> without the mapping, step 5 can't be done (i.e. before purgatory).
> Freescale said the TLB is always on in my PPC architecture.
- I don't know what rfi does. Can you please tell more.
- I think, once MMU is turned off, TLB will not be used at all. So why
do I need to set TLB to take a jump to start_address(r5)
- Assuming for your PPC platform, somehow TLBs are always needed (as you
mentioned), then can't we set TLB in teardown code (relocate_kernel.S)
#if CONFIG_YOUR_PPC_PLATFORM
Set TLB
#endif
> This TLB (1-to-1) mapping of DRAM is part of the teardown of the current
> kernel. In other words, a trampoline to the new kernel, and has the
> same contextual execution requirements as any preamble to a new kernel.
> The contextual execution requirements means a) self-contained code, b)
> relative addressing, c) No MMU assistance, and d) No interrupts. Given
> that the current page allocator has the capability to allocate
> sequential identity mapped pages, the trampoline and preamble may be
> merged into a single unit, easily. The trampoline should be married to
> the destination kernel, not the tools and not a preconceived notion
> about what will be called or how. The easiest way to decouple the
> current kernel from the destination kernel, is to pass in the identity
> mapped codepage(s) to use on the way to the destination kernel. The
> destination kernel is the only code that knows the proper preamble
> (calling sequence/register set) for itself. For example, the Linux
> 2.6.18 kernels use a device tree and starting register set, while
> previous kernels used bdinfo, cmdline, initrd, etc.
>
> So, to clarify my terminology slightly: The trampoline is the
> destination kernel relocation code and any required setup to allow a
> jump to somewhere else. The preamble is a set of code that sets up the
> calling sequence to the next kernel, register sets etc. The order of
> operations are: trampoline, preamble, destination kernel. The simplest
> case is where no preamble is required, because the destination kernel
> gets all its information from somewhere else.
>
> From a tools perspective, bdinfo, device tree, and the like are the
> same thing...a segment to be placed in memory at a specific address.
> However, the register sets required to boot those kernels are
> different. If the destination kernel is not Linux, the register set is
> definitely not known. All of this specific information for the
> destination kernel should be in a preamble.
>
> Now about purgatory...
>
> Purgatory is not a custom trampoline, it is part of a userspace tool and
> not the system call. Therefore, if someone only uses the system calls,
> purgatory is not available to them. Purgatory may be a preamble to a
> destination kernel.
>
If you are not using kexec-tools, then you can write your own preamble
code and pass the entry to that code as entry point to kexec system
call. After running trampoline (relocate_kernel.S), kernel will
directly jump to the preamble, and there you can do your OS specific
setup. So kexec, as a system call does provide you the functionality
to load and execute a custom preamble.
If you do want to use kexec-tools, then yes by default it will prepare
a piece of code which sets up the context for the new OS. In a nut shell
it basically switches to appropriate mode (64bit, 32bit or 16bit) depending
on what kind of entry one is making and sets up the registers. My query
here is, what is so OS specific here? Isn't it more platform specific?
So basically code flow is like this.
relocate_kernel.S --> purgatory ----> jump to the OS
> kexec-tools/kexec loads my destination elf file including the
> start_address, and causes the kexec system call to jump to the binary
> form of my elf. So, where is purgatory? In my kernel the purgatory
> code isn't used at all (in PPC), although it is a segment, and gets
> placed in memory. So, where does my TLB update go? If the codepage is
> passed in, its in there. Then, the copy of the kernel to the correct
> location actually works.
I don't know what is actually being compiled in purgatory for PPC as of
today. That you will have to find out as I told you nobody has worked
very actively on PPC arches. Currently only the framework is there and
I think framework is generic enough to boot your elf file on your PPC
subarchitecuture. It is just a matter of putting right pieces together
in a generic manner.
As mentioned previously, your TLB update is more of a platform detail
and not OS detail. I believe it should go in relocate_kernel.S
What's the piece of code in purgatory which is not generic enough and
does not allow you to boot your elf file?
>
> This patch is 1) backwardly 100% compatible with existing tools (doesn't
> remove any kernel code, yet), and 2) enables USERSPACE tools to control
> the codepage trampoline.
>
I still don't understand why codepage is required?
Thanks
Vivek
_______________________________________________
fastboot mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/fastboot
