Add support to build the PS3 flash rom image.
zImage.ps3 is a wrapped image that contains a flat device tree, an lv1
compatible entry point, a wrapper program with a standard entry point,
and an optional initrd. otheros.bld is the gzip compresed rom image built
from zImage.ps3. otheros.bld is suitable for programming into the PS3 boot
flash memory.
Also remove the now unneeded lmb calls in the platform code.
Signed-off-by: Geoff Levand <redacted>
---
arch/powerpc/boot/Makefile | 21 ++--
arch/powerpc/boot/ps3-head.S | 84 ++++++++++++++++
arch/powerpc/boot/ps3-hvcall.S | 184 +++++++++++++++++++++++++++++++++++++
arch/powerpc/boot/ps3.c | 158 +++++++++++++++++++++++++++++++
arch/powerpc/boot/wrapper | 55 +++++++++++
arch/powerpc/boot/zImage.ps3.lds.S | 50 ++++++++++
arch/powerpc/platforms/ps3/mm.c | 2
7 files changed, 543 insertions(+), 11 deletions(-)
@@ -230,7 +233,7 @@ install: $(CONFIGURE) $(addprefix $(obj)# anything not in $(targets)clean-files+=$(image-)$(initrd-)zImagezImage.initrdcuImage.*\-treeImage.*zImage.dtszImage.dts_initrd+treeImage.*zImage.dtszImage.dts_initrdotheros.bld# clean up files cached by wrapperclean-kernel:=vmlinux.stripvmlinux.bin---/dev/null+++b/arch/powerpc/boot/ps3-head.S
@@ -239,4 +248,50 @@ treeboot*)fiexit0;;+ps3)+ # The ps3's loader supports loading gzipped binary images from flash+ # rom to addr zero. The loader enters the image at addr 0x100. A+ # bootwrapper overlay is use to arrange for the kernel to be loaded+ # to addr zero and to have a suitable bootwrapper entry at 0x100.+ # To construct the rom image, 0x100 bytes from offset 0x100 in the+ # kernel is copied to the bootwrapper symbol __system_reset_kernel.+ # The 0x100 bytes at the bootwrapper symbol __system_reset_overlay is+ # then copied to offset 0x100. At runtime the bootwrapper program+ # copies the 0x100 bytes at __system_reset_kernel to addr 0x100.++system_reset_overlay=0x`${CROSS}nm"$ofile"\+|grep' __system_reset_overlay$'\+|cut-d' '-f1`+system_reset_overlay=`printf"%d"$system_reset_overlay`+system_reset_kernel=0x`${CROSS}nm"$ofile"\+|grep' __system_reset_kernel$'\+|cut-d' '-f1`+system_reset_kernel=`printf"%d"$system_reset_kernel`+overlay_dest="256"+overlay_size="256"++rm-f"$object/otheros.bld"++${CROSS}objcopy-Obinary"$ofile""$ofile.bin"++msg=$(ddif="$ofile.bin"of="$ofile.bin"conv=notrunc\+skip=$overlay_destseek=$system_reset_kernel\+count=$overlay_sizebs=12>&1)++ if [ $? -ne "0" ]; then+echo$msg+exit1+fi++msg=$(ddif="$ofile.bin"of="$ofile.bin"conv=notrunc\+skip=$system_reset_overlayseek=$overlay_dest\+count=$overlay_sizebs=12>&1)++ if [ $? -ne "0" ]; then+echo$msg+exit2+fi++gzip--force-9--stdout"$ofile.bin">"$object/otheros.bld"+;;esac---/dev/null+++b/arch/powerpc/boot/zImage.ps3.lds.S
From: Milton Miller <hidden> Date: 2007-06-18 14:20:05
On Sat Jun 16 08:07:06 EST 2007, Geoff Levand wrote:
quoted hunk
zImage.ps3 is a wrapped image that contains a flat device tree, an lv1
compatible entry point, a wrapper program with a standard entry point,
and an optional initrd. otheros.bld is the gzip compresed rom image
built
from zImage.ps3. otheros.bld is suitable for programming into the PS3
boot
flash memory.
Also remove the now unneeded lmb calls in the platform code.
Signed-off-by: Geoff Levand <geoffrey.levand at am.sony.com>
---
arch/powerpc/boot/Makefile | 21 ++--
arch/powerpc/boot/ps3-head.S | 84 ++++++++++++++++
arch/powerpc/boot/ps3-hvcall.S | 184
+++++++++++++++++++++++++++++++++++++
arch/powerpc/boot/ps3.c | 158
+++++++++++++++++++++++++++++++
arch/powerpc/boot/wrapper | 55 +++++++++++
arch/powerpc/boot/zImage.ps3.lds.S | 50 ++++++++++
arch/powerpc/platforms/ps3/mm.c | 2
7 files changed, 543 insertions(+), 11 deletions(-)
The policy so far has been code for all platforms is compiled for all
invocations of make in the boot directory. Therefore just add your
files directly to src-plat. If needed, add a flags override to set the
cpu type.
@@ -0,0 +1,84 @@+/*+ * PS3 bootwrapper entry.+ *+ * Copyright (C) 2007 Sony Computer Entertainment Inc.+ * Copyright 2007 Sony Corp.+ *+ * This program is free software; you can redistribute it and/or
modify
+ * it under the terms of the GNU General Public License as published
by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA
+ */
+
+#include "ppc_asm.h"
+
+ .text
+
+/*
+ * __system_reset_overlay - The PS3 first stage entry.
+ *
+ * The bootwraper build script copies the 0x100 bytes at symbol
+ * __system_reset_overlay to offset 0x100 of the rom image.
+ */
+
+ .globl __system_reset_overlay
+__system_reset_overlay:
+
+ /* Switch to 32-bit mode. */
+
+ mfmsr r9
+ clrldi r9,r9,1
+ mtmsrd r9
+ nop
+
+ /* Get thread number in r3 and branch. */
+
+ mfspr r3, 0x88
+ cntlzw. r3, r3
+ li r4, 0
+ li r5, 0
+ beq 1f
+
+ /* Secondary goes to __secondary_hold in kernel. */
+
+ li r4, 0x60
+ mtctr r4
+ bctr
+
+ /* Primary waits for __secondary_hold_acknowledge. */
+1:
+ li r5, 0x10 /* __secondary_hold_acknowledge */
+ or 28, 28, 28 /* db8cyc */
+
+ ld r4, 0(r5)
+ cmpdi r4, 0
+ beq 1b
(1) The address of __secondary_hold_acknowledge is not stable. It has
changed in the past and may change in the future. (2) This works
because you always have exactly 2 cpus, and your secondary cpu is not
id 0.
Because this is part of the kernel source tree, I'm not opposed to this
usage, but I think some checking would be in order. A comment that
this only works for two cpus with the slave id not being 0, and some
check that nm on the kernel image results in the expected symbol and
value.
Since I'm here, I'll mention that the li to r5 doesn't need to be in
the loop. In fact, the load to r4 could be expressed as 0x10(0) or
better create a symbol and use secondary_ack@l(0) eliminating the need
for r5 and easing the above check.
+
+ /* Primary goes to _zimage_start in wrapper. */
+
+ lis r4, _zimage_start at ha
+ addi r4, r4, _zimage_start at l
+ mtctr r4
+ bctr
+
+/*
+ * __system_reset_kernel - Place holder for the kernel reset vector.
+ *
+ * The bootwrapper build script copies 0x100 bytes from offset 0x100
+ * of the rom image to the symbol __system_reset_kernel. At runtime
+ * the bootwrapper program copies the 0x100 bytes at
__system_reset_kernel
+ * to ram address 0x100. This symbol must occupy 0x100 bytes.
+ */
+
+ .globl __system_reset_kernel
+__system_reset_kernel:
+
+ . = __system_reset_kernel + 0x100
Not bad. Since this code doesn't have to be at any particular
location when it is built (you have no .org or similar, its all PIC), I
don't see anything that couldn't be done from an asm block in the
platform .c file, like the entry point in prpmc2800.c file; that would
save a file in the boot directory. In that case __system_reset_kernel
would be an array of 256 bytes.
[removed ps3-hvcall.S and lmb hack removal from followup]
modify
+ * it under the terms of the GNU General Public License as published
by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA
+ */
+
+#include <stdarg.h>
+#include <stddef.h>
+#include "types.h"
+#include "elf.h"
+#include "string.h"
+#include "stdio.h"
+#include "page.h"
+#include "ops.h"
+
+extern s64 lv1_panic(u64 in_1);
+extern s64 lv1_get_logical_partition_id(u64 *out_1);
+extern s64 lv1_get_logical_ppe_id(u64 *out_1);
+extern s64 lv1_get_repository_node_value(u64 in_1, u64 in_2, u64 in_3,
+ u64 in_4, u64 in_5, u64 *out_1, u64 *out_2);
+
+#ifdef DEBUG
+#define DBG(fmt...) printf(fmt)
+#else
+static inline int __attribute__ ((format (printf, 1, 2))) DBG(
+ const char *fmt, ...) {return 0;}
+#endif
This should be in stdio.h for all. Maybe ops, but that is a bit of a
catch-all and printf is not there.
+
+BSS_STACK(4096);
+
+/* A buffer that may be edited by tools operating on a zImage binary
so as to
+ * edit the command line passed to vmlinux (by setting
/chosen/bootargs).
+ * The buffer is put in it's own section so that tools may locate it
easier.
+ */
+static char cmdline[COMMAND_LINE_SIZE]
+ __attribute__((__section__("__builtin_cmdline")));
+
+static void prep_cmdline(void *chosen)
+{
+ if (cmdline[0] == '\0')
+ getprop(chosen, "bootargs", cmdline,
COMMAND_LINE_SIZE-1);
+ else
+ setprop_str(chosen, "bootargs", cmdline);
+
+ printf("cmdline: '%s'\n", cmdline);
+}
+
+static void ps3_console_write(const char *buf, int len)
+{
+}
I'm guessing your testing was done with some non-empty function that
you are not prepared to release. Otherwise you would not have added
all the printf code. I'm not complaining, just noting for my
observations below.
+
+static void ps3_exit(void)
+{
+ printf("ps3_exit\n");
+ lv1_panic(0); /* zero = no reboot */
+ while (1);
+}
Does the hypervisor give some kind of indication that the code paniced?
A comment telling us users what to expect might be nice.
Based on past comments, I belive that you are not calling the normal
_start() specifically to avoid dragging in zlib. Oh, but you call
prep_cmdline, which means you still get main.c and it drags zlib. I
guess we should move prep_initrd and prep_cmdline. Were you just
skipping prep_kernel?
This code and the concept in your .lds file looks like it could be used
by other platforms in a generic way
(except for the call to ps3_exit which should be exit, and the call to
ps3_copy_vectors, which can be moved earlier. While its likely similar
functionality would be needed, the details of what to patch and copy
may vary).
@@ -239,4 +248,50 @@ treeboot*) fi exit 0 ;;+ps3)+ # The ps3's loader supports loading gzipped binary images from
flash
+ # rom to addr zero. The loader enters the image at addr 0x100. A
+ # bootwrapper overlay is use to arrange for the kernel to be
loaded
+ # to addr zero and to have a suitable bootwrapper entry at 0x100.
+ # To construct the rom image, 0x100 bytes from offset 0x100 in the
+ # kernel is copied to the bootwrapper symbol
__system_reset_kernel.
+ # The 0x100 bytes at the bootwrapper symbol
__system_reset_overlay is
+ # then copied to offset 0x100. At runtime the bootwrapper program
+ # copies the 0x100 bytes at __system_reset_kernel to addr 0x100.
+
+ system_reset_overlay=0x`${CROSS}nm "$ofile" \
+ | grep ' __system_reset_overlay$' \
+ | cut -d' ' -f1`
+ system_reset_overlay=`printf "%d" $system_reset_overlay`
+ system_reset_kernel=0x`${CROSS}nm "$ofile" \
+ | grep ' __system_reset_kernel$' \
+ | cut -d' ' -f1`
+ system_reset_kernel=`printf "%d" $system_reset_kernel`
+ overlay_dest="256"
+ overlay_size="256"
+
+ rm -f "$object/otheros.bld"
+
+ ${CROSS}objcopy -O binary "$ofile" "$ofile.bin"
+
+ msg=$(dd if="$ofile.bin" of="$ofile.bin" conv=notrunc \
+ skip=$overlay_dest seek=$system_reset_kernel \
+ count=$overlay_size bs=1 2>&1)
+
+ if [ $? -ne "0" ]; then
+ echo $msg
+ exit 1
+ fi
+
+ msg=$(dd if="$ofile.bin" of="$ofile.bin" conv=notrunc \
+ skip=$system_reset_overlay seek=$overlay_dest \
+ count=$overlay_size bs=1 2>&1)
+
+ if [ $? -ne "0" ]; then
+ echo $msg
+ exit 2
+ fi
+
+ gzip --force -9 --stdout "$ofile.bin" > "$object/otheros.bld"
+ ;;
esac
You don't seem to relocate the initrd. Your lds file has the initrd on
the 4k page boundary after the dtb, which is after the kernel as copied
by objcopy -O binary. As far as I know, objcopy only copies the load
sections; it doesn't create space in the output binary image for alloc
only sections. What prevents the initrd from being in the kernel bss,
which it clears before even looking at the device tree? For that
matter, what prevents the device tree from being allocated in this bss
range?
I'm guessing that you tested with some additional code to display the
console output, which made _end be above the kernel _end, or close
enough that the finalized bss was above the kernel _end? Did you test
an initrd? I guess an attached initrd would also solve the problem of
the final dtb being overwritten, but not the start of the initrd.
I think your approach to the image layout has promise but still needs
some refinement. To solve the problem of where is the kernel end, I
would create a section to hold the kernel elf header and use the
elf_parse routines that are now conveniently in a separate file. The
wrapper script would dd off the header and then it would be linked into
the wrapper like the other sections. At that point the initrd could be
moved before creating the malloc pool above it.
This approach can be used whenever there is something capable of
installing an image at address 0 in ram before starting its execution,
and is useful when the time to install that image is less than the time
to decompress the kernel (and copy either it or the zImage, for the
case where the entry point is fixed in low memory). I can think of
other platforms where this holds true. In your case, this is true
because the hypervisor decompresses the image.
What should this type of image be called? Its not really a zImage,
since there is nothing compressed (well, maybe the initrd/initramfs).
uImage is already taken (u would have stood for uncompressed).
Something like wrapped image? flat image? combined image? We'd still
do make zImage to invoke make for it.
One more point. You indicated that this image had a standard entry
point. Were you thinking it will be used for kexec? Or were you just
trying to state you used the library _zimage_start? While the current
kexec-tools for 64-bit assumes the entry point to be image offset 0,
the same address is used for both the boot cpu entry point and the
address of the slave code to copy to address 0. If you want the master
to execute the wrapper code, you will need to patch the branch at
address 0 in the kernel image to go to _zimage_start in the wrapper,
and then from the wrapper patch it back before starting the kernel. Or
perhaps you don't plan to run the wrapper on the kexec path? In that
case the system reset handler would retained the patched handler and
the initrd ignored would be ignored. While you usage may not care,
other platforms use the system reset vector. In either case,
_zimage_start doesn't have the necessary slave code, and therefore
shouldn't be the entry point for the final image when we fix that bug
in kexec-tools.
milton
The policy so far has been code for all platforms is compiled for all
invocations of make in the boot directory. Therefore just add your
files directly to src-plat. If needed, add a flags override to set the
cpu type.
OK, I can do that. I don't think it is a good way, but I will do it.
The separate rule here is to pick up ps3.dts, correct?
After Marc's 3 patch series this would be handled by the config file.
Yes, these rules will need to be re-worked, but the current form
will continue to work with those changes.
quoted
+ * __system_reset_overlay - The PS3 first stage entry.
+ *
+ * The bootwraper build script copies the 0x100 bytes at symbol
+ * __system_reset_overlay to offset 0x100 of the rom image.
+ */
+
+ .globl __system_reset_overlay
+__system_reset_overlay:
+
+ /* Switch to 32-bit mode. */
+
+ mfmsr r9
+ clrldi r9,r9,1
+ mtmsrd r9
+ nop
+
+ /* Get thread number in r3 and branch. */
+
+ mfspr r3, 0x88
+ cntlzw. r3, r3
+ li r4, 0
+ li r5, 0
+ beq 1f
+
+ /* Secondary goes to __secondary_hold in kernel. */
+
+ li r4, 0x60
+ mtctr r4
+ bctr
+
+ /* Primary waits for __secondary_hold_acknowledge. */
+1:
+ li r5, 0x10 /* __secondary_hold_acknowledge */
+ or 28, 28, 28 /* db8cyc */
+
+ ld r4, 0(r5)
+ cmpdi r4, 0
+ beq 1b
(1) The address of __secondary_hold_acknowledge is not stable. It has
changed in the past and may change in the future. (2) This works
because you always have exactly 2 cpus, and your secondary cpu is not
id 0.
Yes, it is simplified and PS3 specific.
Because this is part of the kernel source tree, I'm not opposed to this
usage, but I think some checking would be in order. A comment that
this only works for two cpus with the slave id not being 0, and some
check that nm on the kernel image results in the expected symbol and
value.
I can make it work without using __secondary_hold_acknowledge by just
using a delay, but it is not as precise.
Since I'm here, I'll mention that the li to r5 doesn't need to be in
the loop. In fact, the load to r4 could be expressed as 0x10(0) or
better create a symbol and use secondary_ack@l(0) eliminating the need
for r5 and easing the above check.
Seems like a cleaner way, but I don't think it is a good idea to use
__secondary_hold_acknowledge if it is not well known, so I will avoid
its use.
quoted
+
+ /* Primary goes to _zimage_start in wrapper. */
+
+ lis r4, _zimage_start at ha
+ addi r4, r4, _zimage_start at l
+ mtctr r4
+ bctr
+
+/*
+ * __system_reset_kernel - Place holder for the kernel reset vector.
+ *
+ * The bootwrapper build script copies 0x100 bytes from offset 0x100
+ * of the rom image to the symbol __system_reset_kernel. At runtime
+ * the bootwrapper program copies the 0x100 bytes at
__system_reset_kernel
+ * to ram address 0x100. This symbol must occupy 0x100 bytes.
+ */
+
+ .globl __system_reset_kernel
+__system_reset_kernel:
+
+ . = __system_reset_kernel + 0x100
Not bad. Since this code doesn't have to be at any particular
location when it is built (you have no .org or similar, its all PIC), I
don't see anything that couldn't be done from an asm block in the
platform .c file, like the entry point in prpmc2800.c file; that would
save a file in the boot directory.
For me that would be a significant effort, and I don't think I can
consolidate them for 2.6.23. I will consider it for 2.6.24.
quoted
+BSS_STACK(4096);
+
+/* A buffer that may be edited by tools operating on a zImage binary
so as to
+ * edit the command line passed to vmlinux (by setting
/chosen/bootargs).
+ * The buffer is put in it's own section so that tools may locate it
easier.
+ */
+static char cmdline[COMMAND_LINE_SIZE]
+ __attribute__((__section__("__builtin_cmdline")));
+
+static void prep_cmdline(void *chosen)
+{
+ if (cmdline[0] == '\0')
+ getprop(chosen, "bootargs", cmdline,
COMMAND_LINE_SIZE-1);
+ else
+ setprop_str(chosen, "bootargs", cmdline);
+
+ printf("cmdline: '%s'\n", cmdline);
+}
+
+static void ps3_console_write(const char *buf, int len)
+{
+}
I'm guessing your testing was done with some non-empty function that
you are not prepared to release. Otherwise you would not have added
all the printf code. I'm not complaining, just noting for my
observations below.
Someone might be interested in making ps3_console_write() save the
messages to memory and print them later, so I thought it wold be
good to leave the printf's in.
quoted
+
+static void ps3_exit(void)
+{
+ printf("ps3_exit\n");
+ lv1_panic(0); /* zero = no reboot */
+ while (1);
+}
Does the hypervisor give some kind of indication that the code paniced?
A comment telling us users what to expect might be nice.
The lpar will be shutdown. Non-zero will make it reboot. That is the
documented behavior. If I get a better idea of what it will do I will
put in a better comment.
Based on past comments, I belive that you are not calling the normal
_start() specifically to avoid dragging in zlib. Oh, but you call
prep_cmdline, which means you still get main.c and it drags zlib. I
guess we should move prep_initrd and prep_cmdline. Were you just
skipping prep_kernel?
I was hoping to eventually get rid of most of the unused stuff that
is now linked in, but for now I just need something working.
This code and the concept in your .lds file looks like it could be used
by other platforms in a generic way
(except for the call to ps3_exit which should be exit, and the call to
ps3_copy_vectors, which can be moved earlier. While its likely similar
functionality would be needed, the details of what to patch and copy
may vary).
I did try to make it generic in my initial RFC's but it wasn't well
received, so I just went with a platform specific approach and tried
to simplify it.
You don't seem to relocate the initrd. Your lds file has the initrd on
the 4k page boundary after the dtb, which is after the kernel as copied
by objcopy -O binary. As far as I know, objcopy only copies the load
sections; it doesn't create space in the output binary image for alloc
only sections. What prevents the initrd from being in the kernel bss,
which it clears before even looking at the device tree? For that
matter, what prevents the device tree from being allocated in this bss
range?
Yes, a point I missed. I think it is easier to just make objcopy output
the bss, so that is what I'll do for now.
objflags="-O binary --set-section-flags=.bss=contents,alloc,load,readonly,data"
I'll consider doing a relocation later.
I'm guessing that you tested with some additional code to display the
console output, which made _end be above the kernel _end, or close
enough that the finalized bss was above the kernel _end? Did you test
an initrd? I guess an attached initrd would also solve the problem of
the final dtb being overwritten, but not the start of the initrd.
No, I did not test initrd, so it is still todo.
I think your approach to the image layout has promise but still needs
some refinement. To solve the problem of where is the kernel end, I
would create a section to hold the kernel elf header and use the
elf_parse routines that are now conveniently in a separate file. The
wrapper script would dd off the header and then it would be linked into
the wrapper like the other sections. At that point the initrd could be
moved before creating the malloc pool above it.
OK, I'll consider it.
This approach can be used whenever there is something capable of
installing an image at address 0 in ram before starting its execution,
and is useful when the time to install that image is less than the time
to decompress the kernel (and copy either it or the zImage, for the
case where the entry point is fixed in low memory). I can think of
other platforms where this holds true. In your case, this is true
because the hypervisor decompresses the image.
What should this type of image be called? Its not really a zImage,
since there is nothing compressed (well, maybe the initrd/initramfs).
uImage is already taken (u would have stood for uncompressed).
Something like wrapped image? flat image? combined image? We'd still
do make zImage to invoke make for it.
At this point I just want to get my platform code included so distros
can start to use it. I don't want to turn this patch into an effort to
provide a new generic kernel infrastructure. That should be a different
effort, then when that is ready we can switch this code over.
One more point. You indicated that this image had a standard entry
point. Were you thinking it will be used for kexec? Or were you just
trying to state you used the library _zimage_start?
I was thinking kexec. My initial work was to add zImage support to
kexec, but I dropped that to focus on getting the bootwrapper and
kexec of vmlinux working. I have no plan to restart that work
so will drop that part of the comment.
I'll send out an updated patch.
-Geoff
Add support to build the PS3 flash rom image.
zImage.ps3 is a wrapped image that contains a flat device tree, an lv1
compatible entry point, and an optional initrd. otheros.bld is the gzip
compresed rom image built from zImage.ps3. otheros.bld is suitable for
programming into the PS3 boot flash memory.
Also remove the now unneeded lmb calls in the platform code.
Signed-off-by: Geoff Levand <redacted>
---
v2 changes:
o Make platform specific files build for all platforms.
o Remove use of __secondary_hold_acknowledge.
o Change patch comment about zImage entry.
o Add comment about lv1_panic() to ps3_exit().
o Make room for bss section in otheros.bld.
arch/powerpc/boot/Makefile | 20 ++--
arch/powerpc/boot/ps3-head.S | 80 ++++++++++++++++
arch/powerpc/boot/ps3-hvcall.S | 184 +++++++++++++++++++++++++++++++++++++
arch/powerpc/boot/ps3.c | 161 ++++++++++++++++++++++++++++++++
arch/powerpc/boot/wrapper | 55 +++++++++++
arch/powerpc/boot/zImage.ps3.lds.S | 50 ++++++++++
arch/powerpc/platforms/ps3/mm.c | 2
7 files changed, 541 insertions(+), 11 deletions(-)
@@ -230,7 +232,7 @@ install: $(CONFIGURE) $(addprefix $(obj)# anything not in $(targets)clean-files+=$(image-)$(initrd-)zImagezImage.initrdcuImage.*\-treeImage.*zImage.dtszImage.dts_initrd+treeImage.*zImage.dtszImage.dts_initrdotheros.bld# clean up files cached by wrapperclean-kernel:=vmlinux.stripvmlinux.bin---/dev/null+++b/arch/powerpc/boot/ps3-head.S
@@ -239,4 +248,50 @@ treeboot*)fiexit0;;+ps3)+ # The ps3's loader supports loading gzipped binary images from flash+ # rom to addr zero. The loader enters the image at addr 0x100. A+ # bootwrapper overlay is use to arrange for the kernel to be loaded+ # to addr zero and to have a suitable bootwrapper entry at 0x100.+ # To construct the rom image, 0x100 bytes from offset 0x100 in the+ # kernel is copied to the bootwrapper symbol __system_reset_kernel.+ # The 0x100 bytes at the bootwrapper symbol __system_reset_overlay is+ # then copied to offset 0x100. At runtime the bootwrapper program+ # copies the 0x100 bytes at __system_reset_kernel to addr 0x100.++system_reset_overlay=0x`${CROSS}nm"$ofile"\+|grep' __system_reset_overlay$'\+|cut-d' '-f1`+system_reset_overlay=`printf"%d"$system_reset_overlay`+system_reset_kernel=0x`${CROSS}nm"$ofile"\+|grep' __system_reset_kernel$'\+|cut-d' '-f1`+system_reset_kernel=`printf"%d"$system_reset_kernel`+overlay_dest="256"+overlay_size="256"++rm-f"$object/otheros.bld"++${CROSS}objcopy-Obinary"$ofile""$ofile.bin"++msg=$(ddif="$ofile.bin"of="$ofile.bin"conv=notrunc\+skip=$overlay_destseek=$system_reset_kernel\+count=$overlay_sizebs=12>&1)++ if [ $? -ne "0" ]; then+echo$msg+exit1+fi++msg=$(ddif="$ofile.bin"of="$ofile.bin"conv=notrunc\+skip=$system_reset_overlayseek=$overlay_dest\+count=$overlay_sizebs=12>&1)++ if [ $? -ne "0" ]; then+echo$msg+exit2+fi++gzip--force-9--stdout"$ofile.bin">"$object/otheros.bld"+;;esac---/dev/null+++b/arch/powerpc/boot/zImage.ps3.lds.S
The separate rule here is to pick up ps3.dts, correct?
After Marc's 3 patch series this would be handled by the config file.
^ k :)
Yep. Hack the appropriate Kconfig to 'select WANT_DEVICE_TREE'
then make config to set DEVICE_TREE to the name of your dts file
(e.g., ps3.dts). See configs/prpmc2800_defconfig for an example.
The patches Milton is referring to are at:
http://patchwork.ozlabs.org/linuxppc/patch?id=11428 + 11429 + 11430
quoted
+
+ /* Primary goes to _zimage_start in wrapper. */
+
+ lis r4, _zimage_start at ha
+ addi r4, r4, _zimage_start at l
+ mtctr r4
+ bctr
+
+/*
+ * __system_reset_kernel - Place holder for the kernel reset vector.
+ *
+ * The bootwrapper build script copies 0x100 bytes from offset 0x100
+ * of the rom image to the symbol __system_reset_kernel. At runtime
+ * the bootwrapper program copies the 0x100 bytes at
__system_reset_kernel
+ * to ram address 0x100. This symbol must occupy 0x100 bytes.
+ */
+
+ .globl __system_reset_kernel
+__system_reset_kernel:
+
+ . = __system_reset_kernel + 0x100
Not bad. Since this code doesn't have to be at any particular
location when it is built (you have no .org or similar, its all PIC), I
don't see anything that couldn't be done from an asm block in the
platform .c file, like the entry point in prpmc2800.c file; that would
save a file in the boot directory. In that case __system_reset_kernel
would be an array of 256 bytes.
Agree.
As for the rest of Geoff's patch, I think I get the gist of what's going
on but it would be really nice to have it described in English (and put
in the patch description). That way others (like me) could understand
the problem you're solving and what your solution is.
(Hey, Paul made me do that so you can too! ;)
Mark
Not bad. Since this code doesn't have to be at any particular
location when it is built (you have no .org or similar, its all PIC), I
don't see anything that couldn't be done from an asm block in the
platform .c file, like the entry point in prpmc2800.c file; that would
save a file in the boot directory. In that case __system_reset_kernel
would be an array of 256 bytes.
Agree.
As for the rest of Geoff's patch, I think I get the gist of what's going
on but it would be really nice to have it described in English (and put
in the patch description). That way others (like me) could understand
the problem you're solving and what your solution is.
This is from the comment the patch adds to the wrapper script. I think
it gives you what you need:
+ps3)
+ # The ps3's loader supports loading gzipped binary images from flash
+ # rom to addr zero. The loader enters the image at addr 0x100. A
+ # bootwrapper overlay is use to arrange for the kernel to be loaded
+ # to addr zero and to have a suitable bootwrapper entry at 0x100.
+ # To construct the rom image, 0x100 bytes from offset 0x100 in the
+ # kernel is copied to the bootwrapper symbol __system_reset_kernel.
+ # The 0x100 bytes at the bootwrapper symbol __system_reset_overlay is
+ # then copied to offset 0x100. At runtime the bootwrapper program
+ # copies the 0x100 bytes at __system_reset_kernel to addr 0x100.
From: Mark A. Greer <hidden> Date: 2007-06-19 06:01:22
On Mon, Jun 18, 2007 at 05:01:43PM -0700, Geoff Levand wrote:
Mark A. Greer wrote:
quoted
As for the rest of Geoff's patch, I think I get the gist of what's going
on but it would be really nice to have it described in English (and put
in the patch description). That way others (like me) could understand
the problem you're solving and what your solution is.
This is from the comment the patch adds to the wrapper script. I think
it gives you what you need:
+ps3)
+ # The ps3's loader supports loading gzipped binary images from flash
+ # rom to addr zero. The loader enters the image at addr 0x100. A
+ # bootwrapper overlay is use to arrange for the kernel to be loaded
+ # to addr zero and to have a suitable bootwrapper entry at 0x100.
+ # To construct the rom image, 0x100 bytes from offset 0x100 in the
+ # kernel is copied to the bootwrapper symbol __system_reset_kernel.
+ # The 0x100 bytes at the bootwrapper symbol __system_reset_overlay is
+ # then copied to offset 0x100. At runtime the bootwrapper program
+ # copies the 0x100 bytes at __system_reset_kernel to addr 0x100.
Yes, that was what I needed. I should have found that myself...my apologies.
Mark
From: Paul Mackerras <hidden> Date: 2007-06-19 06:44:39
Geoff Levand writes:
This is from the comment the patch adds to the wrapper script. I think
it gives you what you need:
+ps3)
+ # The ps3's loader supports loading gzipped binary images from flash
+ # rom to addr zero. The loader enters the image at addr 0x100. A
+ # bootwrapper overlay is use to arrange for the kernel to be loaded
+ # to addr zero and to have a suitable bootwrapper entry at 0x100.
+ # To construct the rom image, 0x100 bytes from offset 0x100 in the
+ # kernel is copied to the bootwrapper symbol __system_reset_kernel.
+ # The 0x100 bytes at the bootwrapper symbol __system_reset_overlay is
+ # then copied to offset 0x100. At runtime the bootwrapper program
+ # copies the 0x100 bytes at __system_reset_kernel to addr 0x100.
Yes, that is useful, but Mark is right, your patch description is a
bit terse, and something like that in the patch description would be
useful.
Paul.
-----Original Message-----
From: Paul Mackerras [mailto:paulus@samba.org]
Sent: Mon 6/18/2007 11:44 PM
To: Levand, Geoffrey
Cc: Mark A. Greer; ppcdev; Milton Miller
Subject: Re: [patch 30/33] PS3: Bootwrapper support.
=20
Geoff Levand writes:
This is from the comment the patch adds to the wrapper script. I =
think
it gives you what you need:
=20
+ps3)
+ # The ps3's loader supports loading gzipped binary images from =
flash
+ # rom to addr zero. The loader enters the image at addr 0x100. A
+ # bootwrapper overlay is use to arrange for the kernel to be =
loaded
+ # to addr zero and to have a suitable bootwrapper entry at 0x100.
+ # To construct the rom image, 0x100 bytes from offset 0x100 in =
the
+ # kernel is copied to the bootwrapper symbol =
__system_reset_kernel.
+ # The 0x100 bytes at the bootwrapper symbol =
__system_reset_overlay is
+ # then copied to offset 0x100. At runtime the bootwrapper =
program
+ # copies the 0x100 bytes at __system_reset_kernel to addr 0x100.
Yes, that is useful, but Mark is right, your patch description is a
bit terse, and something like that in the patch description would be
useful.
I prepared a new patch with this description and was waiting a while to =
get
all the comments. I'll send it out soon.
-Geoff
Subject: PS3: Bootwrapper support.
Add support to build the PS3 flash rom image and remove some unneeded
lmb calls.
The PS3's lv1 loader supports loading gzipped binary images from flash
rom to addr zero. The loader enters the image at addr 0x100.
In this implementation a bootwrapper overlay is use to arrange for the kernel to
be loaded to addr zero and to have a suitable bootwrapper entry at 0x100. To
construct the rom image, 0x100 bytes from offset 0x100 in the kernel is copied
to the bootwrapper symbol __system_reset_kernel. The 0x100 bytes at the
bootwrapper symbol __system_reset_overlay is then copied to offset 0x100. At
runtime the bootwrapper program copies the 0x100 bytes at __system_reset_kernel
to addr 0x100.
zImage.ps3 is a wrapped image that contains a flat device tree, an lv1
compatible entry point, and an optional initrd. otheros.bld is the gzip
compresed rom image built from zImage.ps3. otheros.bld is suitable for
programming into the PS3 boot flash memory.
Signed-off-by: Geoff Levand <redacted>
---
v3 changes:
o Add details about PS3 loader to patch description.
v2 changes:
o Make platform specific files build for all platforms.
o Remove use of __secondary_hold_acknowledge.
o Change patch comment about zImage entry.
o Add comment about lv1_panic() to ps3_exit().
o Make room for bss section in otheros.bld.
arch/powerpc/boot/Makefile | 20 ++--
arch/powerpc/boot/ps3-head.S | 80 ++++++++++++++++
arch/powerpc/boot/ps3-hvcall.S | 184 +++++++++++++++++++++++++++++++++++++
arch/powerpc/boot/ps3.c | 161 ++++++++++++++++++++++++++++++++
arch/powerpc/boot/wrapper | 55 +++++++++++
arch/powerpc/boot/zImage.ps3.lds.S | 50 ++++++++++
arch/powerpc/platforms/ps3/mm.c | 2
7 files changed, 541 insertions(+), 11 deletions(-)
@@ -230,7 +232,7 @@ install: $(CONFIGURE) $(addprefix $(obj)# anything not in $(targets)clean-files+=$(image-)$(initrd-)zImagezImage.initrdcuImage.*\-treeImage.*zImage.dtszImage.dts_initrd+treeImage.*zImage.dtszImage.dts_initrdotheros.bld# clean up files cached by wrapperclean-kernel:=vmlinux.stripvmlinux.bin---/dev/null+++b/arch/powerpc/boot/ps3-head.S
@@ -239,4 +248,50 @@ treeboot*)fiexit0;;+ps3)+ # The ps3's loader supports loading gzipped binary images from flash+ # rom to addr zero. The loader enters the image at addr 0x100. A+ # bootwrapper overlay is use to arrange for the kernel to be loaded+ # to addr zero and to have a suitable bootwrapper entry at 0x100.+ # To construct the rom image, 0x100 bytes from offset 0x100 in the+ # kernel is copied to the bootwrapper symbol __system_reset_kernel.+ # The 0x100 bytes at the bootwrapper symbol __system_reset_overlay is+ # then copied to offset 0x100. At runtime the bootwrapper program+ # copies the 0x100 bytes at __system_reset_kernel to addr 0x100.++system_reset_overlay=0x`${CROSS}nm"$ofile"\+|grep' __system_reset_overlay$'\+|cut-d' '-f1`+system_reset_overlay=`printf"%d"$system_reset_overlay`+system_reset_kernel=0x`${CROSS}nm"$ofile"\+|grep' __system_reset_kernel$'\+|cut-d' '-f1`+system_reset_kernel=`printf"%d"$system_reset_kernel`+overlay_dest="256"+overlay_size="256"++rm-f"$object/otheros.bld"++${CROSS}objcopy-Obinary"$ofile""$ofile.bin"++msg=$(ddif="$ofile.bin"of="$ofile.bin"conv=notrunc\+skip=$overlay_destseek=$system_reset_kernel\+count=$overlay_sizebs=12>&1)++ if [ $? -ne "0" ]; then+echo$msg+exit1+fi++msg=$(ddif="$ofile.bin"of="$ofile.bin"conv=notrunc\+skip=$system_reset_overlayseek=$overlay_dest\+count=$overlay_sizebs=12>&1)++ if [ $? -ne "0" ]; then+echo$msg+exit2+fi++gzip--force-9--stdout"$ofile.bin">"$object/otheros.bld"+;;esac---/dev/null+++b/arch/powerpc/boot/zImage.ps3.lds.S
Subject: PS3: Bootwrapper support.
Add support to build the PS3 flash rom image and remove some unneeded
lmb calls.
The PS3's lv1 loader supports loading gzipped binary images from flash
rom to addr zero. The loader enters the image at addr 0x100.
In this implementation a bootwrapper overlay is use to arrange for the kernel to
be loaded to addr zero and to have a suitable bootwrapper entry at 0x100. To
construct the rom image, 0x100 bytes from offset 0x100 in the kernel is copied
to the bootwrapper symbol __system_reset_kernel. The 0x100 bytes at the
bootwrapper symbol __system_reset_overlay is then copied to offset 0x100. At
runtime the bootwrapper program copies the 0x100 bytes at __system_reset_kernel
to addr 0x100.
zImage.ps3 is a wrapped image that contains a flat device tree, an lv1
compatible entry point, and an optional initrd. otheros.bld is the gzip
compresed rom image built from zImage.ps3. otheros.bld is suitable for
programming into the PS3 boot flash memory.
Signed-off-by: Geoff Levand <redacted>
---
Hi Paul.
I rebased this to your latest for-2.6.23 branch. Please
apply.
-Geoff
v4 changes:
o Rebase to for-2.6.23 branch of powerpc.git.
v3 changes:
o Add details about PS3 loader to patch description.
v2 changes:
o Make platform specific files build for all platforms.
o Remove use of __secondary_hold_acknowledge.
o Change patch comment about zImage entry.
o Add comment about lv1_panic() to ps3_exit().
o Make room for bss section in otheros.bld.
arch/powerpc/boot/Makefile | 21 ++--
arch/powerpc/boot/ps3-head.S | 80 ++++++++++++++++
arch/powerpc/boot/ps3-hvcall.S | 184 +++++++++++++++++++++++++++++++++++++
arch/powerpc/boot/ps3.c | 161 ++++++++++++++++++++++++++++++++
arch/powerpc/boot/wrapper | 55 +++++++++++
arch/powerpc/boot/zImage.ps3.lds.S | 50 ++++++++++
arch/powerpc/platforms/ps3/mm.c | 2
7 files changed, 542 insertions(+), 11 deletions(-)
@@ -206,7 +208,8 @@ install: $(CONFIGURE) $(addprefix $(obj)sh-x$(srctree)/$(src)/install.sh"$(KERNELRELEASE)"vmlinuxSystem.map"$(INSTALL_PATH)"$<# anything not in $(targets)-clean-files+=$(image-)$(initrd-)zImagezImage.initrdcuImage.*treeImage.*+clean-files+=$(image-)$(initrd-)zImagezImage.initrdcuImage.*treeImage.*\+otheros.bld# clean up files cached by wrapperclean-kernel:=vmlinux.stripvmlinux.bin---/dev/null+++b/arch/powerpc/boot/ps3-head.S
@@ -239,4 +248,50 @@ treeboot*)fiexit0;;+ps3)+ # The ps3's loader supports loading gzipped binary images from flash+ # rom to addr zero. The loader enters the image at addr 0x100. A+ # bootwrapper overlay is use to arrange for the kernel to be loaded+ # to addr zero and to have a suitable bootwrapper entry at 0x100.+ # To construct the rom image, 0x100 bytes from offset 0x100 in the+ # kernel is copied to the bootwrapper symbol __system_reset_kernel.+ # The 0x100 bytes at the bootwrapper symbol __system_reset_overlay is+ # then copied to offset 0x100. At runtime the bootwrapper program+ # copies the 0x100 bytes at __system_reset_kernel to addr 0x100.++system_reset_overlay=0x`${CROSS}nm"$ofile"\+|grep' __system_reset_overlay$'\+|cut-d' '-f1`+system_reset_overlay=`printf"%d"$system_reset_overlay`+system_reset_kernel=0x`${CROSS}nm"$ofile"\+|grep' __system_reset_kernel$'\+|cut-d' '-f1`+system_reset_kernel=`printf"%d"$system_reset_kernel`+overlay_dest="256"+overlay_size="256"++rm-f"$object/otheros.bld"++${CROSS}objcopy-Obinary"$ofile""$ofile.bin"++msg=$(ddif="$ofile.bin"of="$ofile.bin"conv=notrunc\+skip=$overlay_destseek=$system_reset_kernel\+count=$overlay_sizebs=12>&1)++ if [ $? -ne "0" ]; then+echo$msg+exit1+fi++msg=$(ddif="$ofile.bin"of="$ofile.bin"conv=notrunc\+skip=$system_reset_overlayseek=$overlay_dest\+count=$overlay_sizebs=12>&1)++ if [ $? -ne "0" ]; then+echo$msg+exit2+fi++gzip--force-9--stdout"$ofile.bin">"$object/otheros.bld"+;;esac---/dev/null+++b/arch/powerpc/boot/zImage.ps3.lds.S