Vivek, 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 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. 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. 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. 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. Roland -----Original Message----- From: Vivek Goyal [mailto:[EMAIL PROTECTED] Sent: Monday, October 30, 2006 2:17 PM To: Roehrich, Roland Cc: [email protected] Subject: Re: [Fastboot] RFC: [patch 1/1] Kexec: allow passed in codepage on sys_kexec_load On Mon, Oct 30, 2006 at 01:23:12PM -0500, Roland Roehrich wrote: > From: Roland M. Roehrich <rroehric at mc.com> > > This patch allows sys_kexec_load to accept a passed in codepage to > trampoline to a destination kernel. The existing code assumed that it > was starting a kernel similar to itself, with a particular set of > registers, and data. The patch allows a codepage to be passed in as the > first segment, which can be customized to the destination kernel. A > different customization is needed when going from a 2.6 arch/ppc to 2.6 > arch/powerpc kernel, or from a 2.6 kernel to a 2.4 kernel, or to a > non-Linux kernel. > Hi Ronald, Why do we need above codepage? Can't the existing purgatory infrastructure handle this? You already got the facility to load a custom trampoline code and pass the pointer to entry of this code through sys_kexec_load(). From kexec-tools perspecitve we call this trampoline code as purgatory. So you can just write your own trampoline and pass it to sys_kexec_load. Are you worried about existing code which is run in relocate_kernel.S? If yes, can you be little specific, what's the piece of code which is not generic enough and does not allow you to boot a 2.4 kernel from 2.6 kernel or does not allow booting to a non-linux kernel? Thanks Vivek _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
