Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 235612
Summary: | RFE: create 'otheros.bld' bootloader image for PlayStation 3 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | David Woodhouse <dwmw2> | ||||||||||
Component: | anaconda | Assignee: | Martin Gracik <mgracik> | ||||||||||
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
Severity: | medium | Docs Contact: | |||||||||||
Priority: | medium | ||||||||||||
Version: | rawhide | CC: | dmach, mnewsome | ||||||||||
Target Milestone: | --- | Keywords: | FutureFeature | ||||||||||
Target Release: | --- | ||||||||||||
Hardware: | All | ||||||||||||
OS: | Linux | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | Doc Type: | Enhancement | |||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2012-07-23 12:48:23 UTC | Type: | --- | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Bug Depends On: | |||||||||||||
Bug Blocks: | 235611 | ||||||||||||
Attachments: |
|
Description
David Woodhouse
2007-04-07 23:58:31 UTC
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 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. 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. 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 > 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_. 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 pnasrat'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 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. Adding FutureFeature keyword to RFE's. mgracik, 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? |