Wednesday, October 27, 2010

AsbestOS Loader Update

Ok i have i spent the better part of the day working on Setting up To compile the Asbestos Kernel. It seems that people are having problems with the Ip address. I plan on removing the set address and replacing them with basic address set. (192.168.2.X and so forth) that would be simpler for the basic user. I will be also working on check for syscall8. and remove the need for only Hermes' payload its not quite fair to the rest of y'all. so i get to learn a little more about peek and poke. instead of using Hermes' syscall8. also going to have a default kernel loaded on the hdd and you be able to chose if you want to load from the usb.

For now here are some thing that might help
== Usage ==

First compile AsbestOS and get a compatible USB exploit delivery mechanism. You
should also connect your PS3 and PC to a network (they need to be in the same
broadcast domain) and make sure your PC allows broadcast packets to UDP port
18194. The IP source and destination are both for these packets.

Run tools/dbgcli to get AsbestOS debug output. Fire off the exploit device, turn
on your PS3 using power followed by eject within 0.2 seconds (if required by
your exploit implementation), and cross your fingers. If you get anything at
all, congratulations, stage2 is running. At this point, if you have any issues,
the problem should be fairly apparent from the messages.

If you get nothing, either the packets aren't making it to your PC or stage2 is
failing to start up properly. If your exploit device can show the debug "print"
USB messages, that might help you find out whether stage2 is at least being
loaded properly.

If your PS3 panics (blinking red light) or spontaneously reboots, then something
somewhere probably hit an error condition. The first thing that stage2 does is
inititalize Ethernet debugging, so chances are either that failed, or stage1

Basically, if stuff doesn't work, poke me on IRC ('marcan' on either EFNet or
freenode) and we'll see what we can do.

To get a kernel to load (see below for instructions to build one), you need to
have a DHCP server on your network. It needs to be configured to feed a boot
server and filename to the PS3. The boot server should point to a machine
running a TFTP server that can serve the specified file, which should be the
kernel image. For example, on an OpenWRT Kamikaze router, put something like
this on your /etc/config/dhcp:

config host
option name ps3
option mac 00:1f:a7:aa:bb:cc
option ip
option networkid ps3

config boot
option networkid ps3
option filename dtbImage.ps3.bin
option servername foobar
option serveraddress

Where is the IP that you want your PS3 to get and is
the IP of the TFTP server. The server name doesn't really matter, but it's a
good idea to set it to the hostname of the TFTP server. Don't forget to specify
the MAC address of your PS3 correctly.
== Kernel ==

Standard ps3-linux.git kernels should work. However, you should reduce the
allocation size for the framebuffer to 2MB or so (and use a small modde, like

If you want early debugging via dbgcli from the kernel, check out the patches
at: . There's also a useful .config

To build the kernel, use 'make dtbImage.ps3'. The binary that you need to use
in your TFTP server is at arch/powerpc/boot/dtbImage.ps3.bin

To specify commandline arguments, edit arch/powerpc/boot/dts/ps3.dts like this:

chosen {
bootargs = "your boot arguments here";

For example, I use the following:

udbg-immortal video=ps3fb:mode:2 root=/dev/nfs rw
nfsroot= ip=dhcp init=/linuxrc

Yes, this is ugly and will change once AsbestOS gains devicetree support.

== Linux environment ==

The GameOS environment is essentially the same as the OtherOS environment, as
they are just different LPAR configurations on the same hypervisor. The
following differences are known to exist:

- Boot memory is 16MB instead of 128MB. This restricts the size of the Linux
kernel (and any initrd) and causes issues with the allocation for the shadow
framebuffer. For now, you need to reduce the framebuffer allocation size. This
will be fixed in the future. One possibility to bypass this is to make
AsbestOS responsible for allocating the rest of RAM, and make Linux use it as
soon as possible (currently, the remaining RAM is added halfway through kernel
startup). Also, as a consequence of the 16MB initial size of RAM, the kernel
uses a silly value for the maximum number of threads. Use a wrapper script
around /sbin/init and poke /proc/sys/kernel/threads-max to work around the
issue. You might also need to run 'ulimit -u unlimited'.

- 3D support is obviously available, but its use is unknown. For all we know 3D
support might actually exist in OtherOS mode too, but it definitely must exist
under GameOS for obvious reasons.

- Flash and HDD access limitations are different. Currently, Linux seems unable
to access these devices out of the box. Investigation needed.

- Linux gets access to an additional SPE, so you get 7 instead of 6.

>>>AsbestOS README
I hope this helps with the people that think its broken, just becuase it panics with no NFS share running.

when you see this screen my App has worked just now the other half of AsbestOS needs to be setup. Just Follow AsbestOS Readme and it should help. anyways next update should be a release.


No comments:

Post a Comment