Bug 235612 - RFE: create 'otheros.bld' bootloader image for PlayStation 3
RFE: create 'otheros.bld' bootloader image for PlayStation 3
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Martin Gracik
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks: 235611
  Show dependency treegraph
 
Reported: 2007-04-07 19:58 EDT by David Woodhouse
Modified: 2013-07-04 08:46 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-23 08:48:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch to upd-instroot to create petitboot initrd template (3.92 KB, patch)
2007-04-07 19:58 EDT, David Woodhouse
no flags Details | Diff
Build otheros.bld (8.94 KB, patch)
2007-04-10 01:00 EDT, David Woodhouse
no flags Details | Diff
simplify script args (3.61 KB, patch)
2007-04-10 11:48 EDT, David Woodhouse
no flags Details | Diff
replacement otheros.bld patch (5.72 KB, patch)
2007-04-10 22:20 EDT, David Woodhouse
no flags Details | Diff

  None (edit)
Description David Woodhouse 2007-04-07 19:58:31 EDT
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
install medium.

Paul, if I update 'mkzimage' in ppc64-utils so that it can create a PS3-style
zImage can you handle finishing this task?
Comment 1 David Woodhouse 2007-04-07 19:58:31 EDT
Created attachment 151924 [details]
patch to upd-instroot to create petitboot initrd template
Comment 2 David Woodhouse 2007-04-08 00:47:28 EDT
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
total 16044
-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.
Comment 3 David Woodhouse 2007-04-10 01:00:10 EDT
Created attachment 152087 [details]
Build otheros.bld

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.
Comment 4 Jeremy Katz 2007-04-10 10:26:31 EDT
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?
Comment 5 David Woodhouse 2007-04-10 11:02:30 EDT
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.
Comment 6 Jeremy Katz 2007-04-10 11:18:10 EDT
(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?  
Comment 7 David Woodhouse 2007-04-10 11:45:21 EDT
(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
> acceptable.

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_.

Comment 8 David Woodhouse 2007-04-10 11:48:01 EDT
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.
Comment 9 David Woodhouse 2007-04-10 22:20:14 EDT
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.
Comment 10 Red Hat Bugzilla 2007-08-21 01:33:23 EDT
User pnasrat@redhat.com's account has been closed
Comment 11 Gary Kindt 2007-10-17 00:14:39 EDT
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.
Comment 12 Greg Morgan 2007-11-11 06:50:44 EST
(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 
styles respectfully.

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 
http://mirror.atrpms.net/fedora/linux/releases/8/Fedora/i386/os/RELEASE-NOTES-en_US.html#sn-ArchSpecific-ppc-install .  
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.
Comment 13 Jon Stanley 2008-04-23 16:29:46 EDT
Adding FutureFeature keyword to RFE's.
Comment 15 David Cantrell 2009-04-14 16:34:08 EDT
mgracik,

Something to keep in mind while working on lorax.
Comment 16 Martin Gracik 2012-04-13 05:08:51 EDT
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?

Note You need to log in before you can comment on or make changes to this bug.