Linux on PlayStation 3 requires a boot image to be programmed into the unit's
flash. This image is just a kernel and initrd bolted together in a zImage.
The initrd contains a graphical bootloader based on kexec and udev.
Attached is a patch which partially implements this; generating the source
directory for the petitboot initrd. It'll need changing to use the minimal
busybox-petitboot instead of the huge busybox-anaconda (bug #235610).
After this is done, the mk-images.ppc script will need to populate the directory
with kernel modules, create the initrd.img and then create a zImage from that
and the kernel. This zImage needs to be named /ps3/otheros/otheros.bld on the
Paul, if I update 'mkzimage' in ppc64-utils so that it can create a PS3-style
zImage can you handle finishing this task?
Created attachment 151924 [details]
patch to upd-instroot to create petitboot initrd template
The bootwrapper part should be done, in ppc64-utils-0.11-3.fc7
It uses the same 'wrapper' shell script as the kernel's boot process. Goes
something like this...
$ mkdir foo ; cd foo
$ /usr/sbin/wrapper -p ps3 -i /boot/initrd-$VER.img /boot/vmlinuz-$VER
$ ls -l
-rw-rw-r-- 1 dwmw2 dwmw2 5377986 2007-04-08 00:41 otheros.bld
-rwxrwxr-x 1 dwmw2 dwmw2 5618434 2007-04-08 00:41 zImage
-rw-rw-r-- 1 dwmw2 dwmw2 27226 2007-04-08 00:41 zImage.map
-rwxrwxr-x 1 dwmw2 dwmw2 13865262 2007-04-08 00:41 zImage.rom
For PS3 we just want the 'otheros.bld' file.
Created attachment 152087 [details]
This is a complete patch, which generates the otheros.bld file and puts it in
the correct place. Please review and apply.
It won't actually do anything useful until the Core+Extras merge, because it
expects the petitboot package to be present.
It also wants the busybox-petitboot package which will be generated when bug
#235610 is addressed, and the kexec-tools package which will be available when
bug 235608 is addressed.
This is complete and utter crack. Complicating all of the calling conventions
of all of the scripts for PS3 is not acceptable, nor is maintaining another list
of packages manually which has to be kept dep clean, etc.
WTF isn't there just a normal bootloader here?
Thanks for the massively constructive feedback.
It isn't really 'complicating all of the calling conventions of all of the
scripts' -- it's adding _one_ directory argument to _two_ of the scripts. If we
were to pass just $TREEDIR to them rather than separately passing the names of
two (now three) subdirectories of $TREEDIR, then that 'complexity' could be
reduced. But as far as I can tell we haven't bothered to do that yet because it
doesn't really matter.
The 'other list of packages' is very minimal; the deps on it really aren't going
to change much. That's another red herring, as far as I can tell.
The real objection seems to be in the final sentence. But that's just the way
the hardware is set up -- it boots directly into a Linux kernel which uses kexec
to boot the distribution kernel. That _is_ the bootloader.
This kexec-based bootloader isn't actually PS3-specific; the initrd generated
should be usable on any architecture which supports kexec. It's not impossible
that people will want to use it elsewhere too.
(In reply to comment #5)
> It isn't really 'complicating all of the calling conventions of all of the
> scripts' -- it's adding _one_ directory argument to _two_ of the scripts. If we
> were to pass just $TREEDIR to them rather than separately passing the names of
> two (now three) subdirectories of $TREEDIR, then that 'complexity' could be
> reduced. But as far as I can tell we haven't bothered to do that yet because it
> doesn't really matter.
It's adding a directory argument that's utterly irrelevant for 99.9% of the
times that people run the scripts, though. And that ends up requiring changes
for any scripts that people have. Which they do. And breaking things for all
of those cases for a single arch is really not acceptable.
> The 'other list of packages' is very minimal; the deps on it really aren't going
> to change much. That's another red herring, as far as I can tell.
If I had a dollar for every time someone told me that deps aren't going to
change much, I'd be pretty rich by now ;-) If it's so unchangeable, then why
aren't we just packaging it up as a single package rather than putting the
complexity into anaconda? Especially as there's going to have to be duplication
here... if this is the only way to boot the PS3, then we're going to have to
have the code somewhere else too.
> The real objection seems to be in the final sentence. But that's just the way
> the hardware is set up -- it boots directly into a Linux kernel which uses kexec
> to boot the distribution kernel. That _is_ the bootloader.
Then why do we have to have all of the kexec bits? If the hardware is set up
that way, why are we doing the work?
(In reply to comment #6)
> It's adding a directory argument that's utterly irrelevant for 99.9% of the
> times that people run the scripts, though. And that ends up requiring changes
> for any scripts that people have. Which they do.
These are internal anaconda scripts, and they actually seem to change quite
often. For a long time, they were different _every_ time I'd look at them.
This argument really seems to be a red herring. But we can _simplify_ the
argument passing -- we can just pass $TREEDIR to mk-images and upd_instroot.
Then the addition of the extra image directory doesn't change the arguments.
> And breaking things for all of those cases for a single arch is really not
By 'all of those cases' you're referring to a few test scripts which currently
poke at the ever-changing internal anaconda scripts? And by 'a single arch' you
mean every arch which might want to use a kexec-based graphical bootloader,
since I already pointed out that it wasn't actually PS3-specific?
> > The 'other list of packages' is very minimal; the deps on it really aren't
> > going to change much. That's another red herring, as far as I can tell.
> If I had a dollar for every time someone told me that deps aren't going to
> change much, I'd be pretty rich by now ;-) If it's so unchangeable, then why
> aren't we just packaging it up as a single package rather than putting the
> complexity into anaconda?
The dependencies don't change, but the _versions_ of the packages in question
obviously do, and anaconda's 'buildinstall' is the right time to build the
initrd because that's the only time you have the final set of packages which are
going into the release.
It would be technically feasible, although suboptimal, to duplicate parts of the
upd_instroot script in the petitboot specfile and create the initrd there. But
aside from the duplication of the extraction logic, then you'd have a snapshot
of older versions of other packages like glibc and udev at the time that
petitboot was created.
> here... if this is the only way to boot the PS3, then we're going to have to
> have the code somewhere else too.
No, you only need to install this once. You can think of it a bit like a BIOS
update. Once you've used the Game OS to install this 'Other OS bootloader',
you're done. When you choose to boot into the 'Other OS', you get straight into
the graphical bootloader which can then kexec whatever you really want to boot
(hard disk, DVD, etc.)
> > The real objection seems to be in the final sentence. But that's just the way
> > the hardware is set up -- it boots directly into a Linux kernel which uses kexec
> > to boot the distribution kernel. That _is_ the bootloader.
> Then why do we have to have all of the kexec bits? If the hardware is set up
> that way, why are we doing the work?
Well, the hardware is set up for that approach but we still have to provide the
kernel+initrd bootloader image as /PS3/otheros/otheros.bld on the install
medium. It has to come from _somewhere_.
Created attachment 152149 [details]
simplify script args
Here's a patch (untested) which simplifies the arguments to mk-images and
upd_instroot. It means that the petitboot patch wouldn't have to change them,
It changes the directories which upd_instroot uses by default if invoked with
no args, and it means you can't run it with the _same_ directory for both $DEST
and $DESTGR -- but as far as I can tell that doesn't work anyway, because the
'tar c | tar x' confuses itself.
Created attachment 152193 [details]
replacement otheros.bld patch
When applied on top of the previous cleanup patch, the one adding petitboot
support no longer changes calling conventions. Now tested.
User firstname.lastname@example.org's account has been closed
Did anyone bother to see how any of the other distros are accomplishing this
"otheros.bld" file construction?
The one OpenSuse has is pretty darned good.
(In reply to comment #11)
> Did anyone bother to see how any of the other distros are accomplishing this
> "otheros.bld" file construction?
> The one OpenSuse has is pretty darned good.
http://en.opensuse.org/PS3 is one of the links that I googled up this morning.
Here's a Fedora how to
http://gregchabala.com/computer/playstation3/howto-linux-on-ps3.php and forum
post here http://forums.fedoraforum.org/showpost.php?p=830225&postcount=7 .
The PS3 world is a semi-open platform. The installation rules go like this:
1.) Partition your PS3 drive to allow Linux to play.
2.) Go to the system menu to install the /PS3/otheros/otheros.bld PS3 firmware
bootloader as per http://www.playstation.com/ps3-openplatform/manual.html .
The directory path must match this string "/PS3/otheros/otheros.bld" and case
maters. Note that only at this point can the system be booted into a
configuration that will accept a Linux installer.
3.) Use the PS3 System menu to switch to the new bootloader firmware as
implemented via the the otheros.bld file.
4.) Perform the normal boot.iso or full DVD installation of Fedora depending
on your choice of network, local media installation, or other installation
What David is asking for in RFE 235612 is a helping hand for the PS3 platform.
It is Sony who is making these conventions and not David. He's asking for the
Sony required boot loader to be in the Sony
required "/PS3/otheros/otheros.bld" location. This is a real nice feature as
it simplifies making the PS3 as a viable Fedora platform. For example, I
followed the release notes
With the knowledge of the required Sony information, I thought yaboot was the
bootloader. I moved yaboot to the "/PS3/otheros/otheros.bld" location to only
have more pain and suffering. This RFE gets my vote because it would have
saved me several hours of messing around by having the correct petitboot,
http://ozlabs.org/~jk/projects/petitboot/ , in the correct location. The four
steps above and the link to the Sony site would be a great readme.txt file for
the the /PS3 directory on the media.
Jeremy thanks for considering David's changes because for starting at $399.00
US$, the PS3 is hot little computing platform.
Adding FutureFeature keyword to RFE's.
Something to keep in mind while working on lorax.
The way the install images are composed now has changed. There's a new tool called lorax doing these. It should be easier to add this support to lorax, than was in the old buildinstall scripts.
But I don't know what is required and I don't have a PS3 to test it on, and I have higher priorities than PS3 right now.
So if anyone is interested in adding the support for PS3, he can let me know, and I can help with the patches.
So does anyone still want to do this?