Hey Geoff,
I'm still thankful today that you're running a PS3 Linux tree via
https://git.kernel.org/pub/scm/linux/kernel/git/geoff/ps3-linux.git!
Good work!
I yesterday tried to compile the newest kernel 4.14 for my PS3 running
OtherOS++ and "Red Ribbon GNU Linux" from 2014. I even succeeded and
created the three *.deb files and installed them afterwards.
Unfortunately, my machine did not boot.
As far as I read in very old sources, this could be that my machine is
using OtherOS++ on firmware 3.55.2 and not the Sony OtherOS prior
firmware 3.2x.
I'm in contact with the creator from "Red Ribbon" and he mentioned we
have to manually patch PS3 linux kernel.
So, my question 1 would be: which patches would I need to get the newest
kernel 4.14 running on my PS3 machine?
Question 2 would be: maybe there exists a second tree where we can get
the kernel for OtherOS++ too?
Maybe there is other stuff I am missing, but as far as I can tell the
sources compile beautifully on the PS3 powerpc machine. Only downside:
it takes 4-5 hours depending on what you selected in the step of "make
menuconfig"...
Thanks so much in advance and have a good time,
Sascha
Hi Sascha,
On 12/08/2017 01:24 AM, Sascha Schroeder wrote:
I yesterday tried to compile the newest kernel 4.14 for my PS3 running
OtherOS++ and "Red Ribbon GNU Linux" from 2014. I even succeeded and
created the three *.deb files and installed them afterwards.
Unfortunately, my machine did not boot.
As far as I read in very old sources, this could be that my machine is
using OtherOS++ on firmware 3.55.2 and not the Sony OtherOS prior
firmware 3.2x.
I'm in contact with the creator from "Red Ribbon" and he mentioned we
have to manually patch PS3 linux kernel.
So, my question 1 would be: which patches would I need to get the newest
kernel 4.14 running on my PS3 machine?
Question 2 would be: maybe there exists a second tree where we can get
the kernel for OtherOS++ too?
Sorry, I don't know. You'll need to ask for help in the hacker
community for OtherOS++.
Maybe there is other stuff I am missing, but as far as I can tell the
sources compile beautifully on the PS3 powerpc machine. Only downside:
it takes 4-5 hours depending on what you selected in the step of "make
menuconfig"...
I highly recommend you cross compile on a PC.
-Geoff
Hey Geoff,
thanks for your time and the clarification!
My firmware is downgradable, this should be possible because it got SS patches. Could be these are from you, so I could go back in fact to 3.15 and try the otheros.bld workaround. Thing is, I don't know if I can split my HDD to use my 110GB Linux; isn't it the case that normal OtherOS only grants you 20GB for Linux? That's the only thing that's holding me back, this way I could even use normal Debian.
I use an old and still working FAT model. The 1400 is a tool model which I don't own.
I don't like what I read about the ABI breakage stuff, to be honest. Especially the second link describes pretty well what happens on my machine. So, current status here is to upgrade to 3.15 kernels only, I think it doesn't make sense to try higher versions at the moment. Is it really "only" a kexec problem? Or something deeper, more difficult? I can try to help but I'm pretty new in this PS3 PowerPC Linux stuff.
Using OtherOS++ was a coincidence. I found this special PUP which splits the HDD in half for Linux and GameOS. This was exactly what I wanted, so I stuck with it. :-) Finding PUPs today which provide Linux options is nearly impossible. I'm not a fan of "Rebug" either, don't want/need it. But they had one firmware with OtherOS++ support which was taken down or whatever. It's just non-existent anymore.
You don't know a community for OtherOS++ by chance? I found some forums online but most of them only care about pirated games (which doesn't interest me at this age anymore) and/or show posts which are highly outdated.
It's pretty hard today to stick with this hardware. But I'm fascinated by the Cell BE and want to learn it. It became a little obsession. So even compiling a kernel on the PS3 doesn't bother me much, I go to work and when I come home the fresh *.deb packages are ready to install. :-D But I understand what you mean of course, will check out cross-compiling.
Geoff, thanks again for your time and wisdom! All the best, Sascha
Am 8. Dezember 2017 18:37:54 MEZ schrieb Geoff Levand [off-list ref]:
Hi Sascha,
On 12/08/2017 01:24 AM, Sascha Schroeder wrote:
quoted
I yesterday tried to compile the newest kernel 4.14 for my PS3
running
quoted
OtherOS++ and "Red Ribbon GNU Linux" from 2014. I even succeeded and
created the three *.deb files and installed them afterwards.
Unfortunately, my machine did not boot.
As far as I read in very old sources, this could be that my machine
is
quoted
using OtherOS++ on firmware 3.55.2 and not the Sony OtherOS prior
firmware 3.2x.
I'm in contact with the creator from "Red Ribbon" and he mentioned we
have to manually patch PS3 linux kernel.
So, my question 1 would be: which patches would I need to get the
Hi Sascha,
On 12/08/2017 01:24 AM, Sascha Schroeder wrote:
quoted
I yesterday tried to compile the newest kernel 4.14 for my PS3 running
OtherOS++ and "Red Ribbon GNU Linux" from 2014. I even succeeded and
created the three *.deb files and installed them afterwards.
Unfortunately, my machine did not boot.
As far as I read in very old sources, this could be that my machine is
using OtherOS++ on firmware 3.55.2 and not the Sony OtherOS prior
firmware 3.2x.
I'm in contact with the creator from "Red Ribbon" and he mentioned we
have to manually patch PS3 linux kernel.
So, my question 1 would be: which patches would I need to get the newest
kernel 4.14 running on my PS3 machine?
I submitted patches to libfdt that resolve this particular ABI breakage
yesterday. If the patch gets merged, newer kernels should become
bootable again.
-Nathan
Hi Nathan,
On 12/08/2017 01:25 PM, Nathan Whitehorn wrote:
I submitted patches to libfdt that resolve this particular ABI breakage yesterday. If the patch gets merged, newer kernels should become bootable again.
Hi Nathan,
On 12/08/2017 01:25 PM, Nathan Whitehorn wrote:
quoted
I submitted patches to libfdt that resolve this particular ABI breakage yesterday. If the patch gets merged, newer kernels should become bootable again.
I found a bug (and updated the pull request), which might help.
The other potential issue is that the fdt_get_property*() API in libfdt
is fundamentally incompatible with the way that V2 device trees align
data accesses since it returns a pointer to a packed structure with both
the property header and data. However, the data in V2 devtrees may be
offset by 4 bytes in a way that depends both on the offset within the
tree and the length of the property and so cannot be represented only as
the tail of a fixed structure. I don't know if Linux uses those
functions; I had to replace two uses in FreeBSD with the equivalent
fdt_getprop*() calls to get things to work.
-Nathan
Sounds like progress! Nice one!
I encountered several issues with this box but still believe Cell can do more.
We're at an incredible architecture right here, what concerns me most is that we still today miss the availability of the mightyness of this machine.
Gallium 0.2 is still working for example, what we need here is people to bring this stuff further.
Heck, I have 7 SPEs on this machine, time to do something useful with these!
220Gflops FTW!
Am 31. Dezember 2017 23:50:14 MEZ schrieb Nathan Whitehorn [off-list ref]:
On 12/12/17 15:05, Geoff Levand wrote:
quoted
Hi Nathan,
On 12/08/2017 01:25 PM, Nathan Whitehorn wrote:
quoted
I submitted patches to libfdt that resolve this particular ABI
breakage yesterday. If the patch gets merged, newer kernels should
become bootable again.
support for older (V2 and V3) device tree to libfdt.)
quoted
I rebased your patch and have it in my ps3-queue
branch, but my ps3 with ps3-petitboot-09.11.30 still
would not boot with it. I didn't spend any time yet
to look into why.
I found a bug (and updated the pull request), which might help.
The other potential issue is that the fdt_get_property*() API in libfdt
is fundamentally incompatible with the way that V2 device trees align
data accesses since it returns a pointer to a packed structure with
both
the property header and data. However, the data in V2 devtrees may be
offset by 4 bytes in a way that depends both on the offset within the
tree and the length of the property and so cannot be represented only
as
the tail of a fixed structure. I don't know if Linux uses those
functions; I had to replace two uses in FreeBSD with the equivalent
fdt_getprop*() calls to get things to work.
-Nathan