Older blog entries for dwmw2 (starting at number 161)

Completed the first install of Fedora rawhide on PlayStation 3 today, from the tree at rsync://bombadil.infradead.org/ps3-rawhide-20070415/

The rawhide kernel works on PS3; all I needed to change was a few things in the installer and related packages. There are updated rhpl, booty, kudzu and anaconda packages, for which the source is in the SRPMS/ directory. All the patches have been filed in bugzilla, findable from the PS3 tracker bug.

There's a bootloader image in PS3/otheros/otheros.bld where the PlayStation will find it if it's burned to DVD. I created it manually with the old 2.6.16 kernel because kexec isn't yet working in the 2.6.21 kernel, but it uses the initrd automatically generated from anaconda with petitboot, which is in Extras.

The biggest issue I have at the moment is that the graphical installer uses a fixed resolution of 800x600 -- which doesn't work too well on a 480i screen, and we default to 480i on PS3. For now, I just added a few options for different video modes into the bootloader configuration in he install tree, and added 'text' to the arguments for the 480i option.

Installing Fedora rawhide on PlayStation 3:

1. Fetch the install tree:
   

   mkdir rawhide-ps3
   cd rawhide-ps3
   rsync -avz rsync://bombadil.infradead.org/rawhide-ps3-20070415/ .
   

   (If you have an existing copy of PPC rawhide lying around already, use that to seed the rsync by copying it into your rawhide-ps3 directory first.)

2. Burn the tree to DVD. From the rawhide-ps3-20070415 directory:
   

   growisofs -Z /dev/dvd -R -J .
   

   If you don't have a DVD writer, you can use the CD image in images/boot.iso to boot and then do a network installation instead. Just export the tree you've downloaded by NFS or HTTP or FTP, and then boot the CD and point it at your export
3. Boot into Game OS and use the self-update procedure to make sure you're running the latest firmware (1.60 at time of writing). Also use the Format Tool to ensure your disk is partitioned such that the "Other OS" is permitted some space. Then install the boot loader and run it as described in the "Performing the Installation" and "Starting the Bootloader" stages of the Sony instructions.
   You might want to note what it says at the bottom about how to get back to Game OS.
4. You should find yourself in the petitboot graphical bootloader. Insert the CD/DVD and within a few seconds, you should see it turn up the screen, with options for different video modes. Select the one you want, or wait 5 seconds and the default (720p) will start.
5. Now you're in the Fedora installer. It should all Just Work™. As is normal on anything but servers where you actually expect to change disks around, make sure you don't use the silly Fedora default partitioning scheme which uses LVM -- choose the option 'Custom' and just make normal partitions on the drive instead. Petitboot isn't yet tested with LVM.
6. When it finishes, it should reboot and petitboot should let you boot from the hard drive. Rebooting doesn't always work yet in the current kernel, so you may need to power cycle when it wants to reboot.
7. When it comes up, run 'yum install smolt' and then 'smoltSendProfile' to let us know that you're running Fedora on PS3.

Note that I've removed all the pointless 64-bit userspace packages which the installer usually installs by default (bug #233427). If for some strange reason you actually want some 64-bit userspace, you'll need to install it yourself later.

All of this is fairly trivial and should land in Fedora rawhide fairly soon, with the possible exception of the otheros.bld bootloader. That currently needs a kernel with working kexec, and a patch to anaconda which doesn't seem to have been received favourably. And even then it may end up producing an image which is too large to fit -- it's possible that we'll need to build a special minimal kernel for use in the bootloader image.

thl writes:

"All this IMHO for a small benefit: to be able to develop i386 packages on a x86_64 host. How big is the number of users doing that? And does it really work in practice? A lot of configure scripts and apps (including rpm) in my experience seem to get confused if you try to compile something for i386 on a x86_64 host (even when remembering to use setarch). So it's really the best and the safest to use a chroot (e.g. mock) for this purposes as far as I can see.

"So in other words: is installing *-devel.i386 packages on x86_64 really a sane default for Fedora? I really doubt it."

Apparently, you're wrong. Building stuff for the secondary arch does "Just Work(tm)", allegedly. I relay this 'information' despite the fact that my own experience is the same as yours -- installing *-devel.ppc64 on ppc64 (which uses all 32-bit userspace by default, since ppc32 isn't as broken an architecture as i386 was) really doesn't make much sense.

This is just one of a bunch of problems with the way we currently handle multilib -- it's time we stopped burying our head in the sand and whining that "multilib hurts", and started actually fixing some of the stupidities which make it hurt. It really doesn't have to be as painful as we have made it for ourselves.

Fedora release 6.92 Rawhide)
Kernel 2.6.20-1.3035.fc7 on an ppc64

ps3 login:

Wheee. The Fedora rawhide kernel finally boots on PlayStation 3. There are a few more details we need to address, like the fact that kexec and reboot aren't working right now, but it looks like we should be in reasonable shape for Fedora 7.

We'll need a bootloader. Ideally that would be petitboot, which the ozlabs folks should have ready any day now, but given the Fedora 7 feature freeze is already upon us I have a horrid suspicion we're going to be making an 'otheros.bld' (flash bootloader for PS3) which we make available separately, and which just has a horrid hack to interpret and obey /etc/yaboot.conf from the hard drive.

When we have more scope to play -- and once kexec actually works in our kernel so it can boot other kernels, which is sort of important for a bootloader -- we'll look at building the bootloader blob properly.

Hm, that 'on an ppc64' still bugs me. I'm sure I submitted a patch to fix it once, long ago when it happened on Alpha.

Again the Fedora release looms and I set about installing rawhide on every PowerPC machine I can find. And again I can't find much wrong with it that's specific to PowerPC.

We thought we'd found one when the kernel wouldn't boot on 32-bit Macs, but that turned out to be a generic memory allocation bug which just happened to be triggered with our configuration by the PowerMac IDE driver. If it hadn't been relatively easy to reproduce in the ppc32 testing, it might have taken much longer to find it.

It's not the first time that the existence of Fedora on PowerPC has had a beneficial effect across all architectures.

There is a petition at http://petitions.pm.gov.uk/iplayer/ imploring the Prime Minister to "prevent the BBC from making its iPlayer on-demand television service available to Windows users only".

While the government doesn't have any direct control over the BBC, they can certainly raise questions about the commercial impartiality which the BBC is supposed to practise.

I'd encourage all UK citizens, even Windows users, to sign up. The problems with the BBC's existing proposals run far deeper than merely restricting access to Windows users.

Much as I hate to advocate the use of dead tree in the 21st century, I actually concluded that was the best way to provide feedback to the BBC about their proposal to inflict DRM on the licence payer and require the use of recent versions of Windows.

It isn't particularly hard to stir up a storm of semi-coherent emails all making the same points -- people can even cut and paste the best bits. You don't have to care much to send an email; it only takes a few moments. Especially amongst the less technical, a real letter unfortunately does seem to hold more weight than contemporary means of communication.

That's why I spent a day or so putting my thoughts down on paper rather than just submitting them electronically -- much to the amazement of those who've heard me rant so frequently about the archaic practice of physically transporting dead tree around the planet.

I'm also very tempted to write to my Member of Parliament about the issue. Although the BBC is independent and doesn't answer directly to Parliament, it is a public body and is held to account by the government for its behaviour.

The BBC is, in general, extremely careful to be seen to be independent -- not just politically but also commercially. To quote but one example, it even goes as far as to make up fictional packets for breakfast cereals in its drama programmes, to avoid "advertising" one particular product even so subtley.

Yet today we see them proposing not only to endorse a single company's commercial product, but to enforce its use, and to exclude all competition. That would be entirely unacceptable behaviour on the part of the BBC, and is the kind of thing which I would expect to lead to discussions in government and a very public slap on the wrist for those concerned.

It's weird, because the BBC know that what they're doing is wrong, and they've even taken steps to correct it in very similar circumstances in the past. In 2003, they renegotiated their contract with the satellite broadcaster BSkyB to ensure that their satellite broadcasts are now unencrypted and can be received by anyone with standard equipment -- rather than being tied in to using equipment from a single vendor.

I hear rumours from insiders that the gratuitous use of DRM is a posterior-covering exercise from a BBC exec; being used to justify certain flawed technical decisions which have been made in the past. As much as I dislike the idea that the rumour could be true, it certainly seems to make more sense than the idea that the BBC have completely lost the plot.

Every BBC licence payer who cares about DRM and/or Free Software should pay attention to their current public consultation and offer feedback.

They have concluded that despite the fact that their content is currently broadcast free-to-air through terrestrial and satellite services, they must inflict gratuitous DRM upon its users when they access it over the Internet.

Furthermore, they conclude that in order to achieve this goal they must mandate the use of recent versions of Windows and its Media Player. Users of any other systems are to be excluded.

My own response to this is partially shown in an Advogato article, and others have commented elsewhere.

Sometimes I really despair of humanity.

From: UK Sales Ops Group <uk_sales_ops@cathaypacific.com>
Cc: david@woodhow.se
Subject: Ticket Refund

Dear Mr Woodhouse,
...

What part of "write down my name again and add an at sign and a dot to make it read David at Woodhou dot s e" is so hard to understand? Why do people see the need to add and change letters?

This one's particularly impressive since after they read "david at woodhouse dot se" back to me I'd gone to the trouble of spelling it out to them -- "h o u dot s e" -- and they still managed to screw it up.

I set up the domain because I thought an email address which is identical to my name except for a couple of bits of punctuation would be far easier to dictate over the phone than my normal address. So far it seems to be harder though.

Extra bonus points to Cathay Pacific for disregarding the explicit instruction on the telephone yesterday that they were not to contact me by telephone but must use email instead. Calling me after their email bounced might have been acceptable (although the incompetence is less so) but they did it before trying to mail me.

Hi David,

It appears that Andrew and Arnold Ltd use IP ranges that are registered as Swedish - this is why you can not view BBC content.

The BBC policy is to only serve broadband content to users who have a UK registered IP address.

Sorry for any disappointment.

Best wishes,

Gina
PC Broadband

[Querying whois.ripe.net]
[whois.ripe.net]
country:        GB
...

Muppets. Is there actually anyone with half a clue left at the BBC? There seems to have been a mass exodus of clue a year or two ago, and it's all gone to pot.

Zaitcev asks: "why in the world does OLPC use OpenFirmware?"

I'm inclined to agree that an after-boot firmware interface is unnecessary; I don't see the point in keeping OpenFirmware alive after the system is booted -- but OpenFirmware does seem to be a good choice as the boot firmware. It's a lot smaller and easier to deal with than Linux-as-bootloader, which we were using before. We only have 1MiB of NOR flash to boot from, and L-A-B was too big. OpenFirmware does the job very nicely.

It's also been a godsend when we've been bringing up the hardware. We've designed entirely new chips for OLPC, and have been working with FPGA versions of them during their lifecycle (the final build with the ASICs of everything should happen this week). Debugging that hardware with OpenFirmware is like magic -- especially if you watch Mitch doing it :)