What is happening at bootup with the memory stick?

[Pikoro]

Has anyone had a looksee at what's going on when the psp is first turned on?

The psp, when first turned on, access the memory stick for about 1.5 seconds before actually booting to the firmware's opening screen.

Could it be looking for a diagnostic program on the memory stick? perhaps something that only sony has? Some kind of failsafe flash loader?

I'm just tossing ideas around here, but is there a way to tap into the memory stick and see what the psp is looking for?

perhaps a "boot loader" could be written that would be run when the psp is first turned on. Finding out what the PSP is looking for would be a first step to seeing what might happen no?

If that's the case, there might be a certain folder that gets accessed that we could try dumping a file with the "bootable" flag set to 1?

Just an idea.

Cheers

[Erant]

I've already discussed this idea earlier, and it is a good idea, but the actual execution might be a problem. I think it to be a good idea because it's really looking for something, not just confirming that there's a memorystick in there, because it does that when booting the GUI. (The memstick icons won't show up at first, only after some slight memstick activity). In order to execute this, you'd have to have one of those Memstick to Memstick Duo converters, and tap the lines into an FPGA or a digital multi-channel oscilloscope. And I have neither...

[th0mas]

Examining the bootstrap code would be the only way to know what it's looking for.

I have a related question.

On the flash0/1 filesystems, there are portions of the kernel that are encrypted.

Wouldn't these modules be loaded in readable RAM in the userspace (as they are callable kernel calls)?

(in other words we could obtain the decrypted modules, providing a better insight, by copying from RAM instead of dumping from the flash)

[mrbrown]

Wouldn't these modules be loaded in readable RAM in the userspace (as they are callable kernel calls)?

No, they are loaded in kernel space and protected from read access by the MMU.

[mrbrown]

The psp, when first turned on, access the memory stick for about 1.5 seconds before actually booting to the firmware's opening screen.

Could it be looking for a diagnostic program on the memory stick? perhaps something that only sony has? Some kind of failsafe flash loader?

It does the same 1.5 second access when you quit out of USB mode, or exit from a game. It's probably rescanning the memory stick for XMB accessible content, such as media and games.

Even if you could log what's going on in those accesses, and you saw something that looked like it wanted to boot a file, how would you figure out the executable format it wanted?

[mrbrown]

Ok, I've had enough of these empty posts with idle speculation and no research. It adds no new or useful information, and it doesn't get you cool points or whatever (I think I've said this before). From now on I'm moving such posts out of PSP Development into General or Off-topic. If it's redundant it gets locked.

Moved.

[mrbrown]

Moved to it's rightful place on the exploit board.

[jimmygoon]

Maybe this is something that could be looked into by examining the contents of the 1.0 Firmware dump... I would but I have no idea about any of this PSP stuff... but I figured... if its doing it at cold-start then it must be in the firmware

sorry if I'm pointing out the obvious :S

[Pikoro]

Another thing i was thinking about is... perhaps it's looking for a theme to be loaded?

I've been playing around with tossing different types of files in different directories on the memory stick.. but haven't really put much time into it since i've been busy with other stuff...

Cheers

[konfig]

If the psp is finding bootable data, the bootable data in the ms may not be files. It may be stored in some boot section, or even in some unknown area.

I know about the ms hardware, so it is only a guess.

[konfig]

Wouldn't these modules be loaded in readable RAM in the userspace (as they are callable kernel calls)?

No, they are loaded in kernel space and protected from read access by the MMU.

Could this mean umd games and ms applications must base on the psp os kernel from the firmware and thus can't take full control of the psp hardware?

It has been found that umd games have their own files to replace the firmware in the memory. How does umd game do this?

[Fabre]

I noticed that in the technical specs, it mentions 4 MB of DRAM. Is the other 32 MB Static RAM? If it is, you could just hook up an external power source to the RAM chip, wait until a point at which the decoded modules would be in RAM, then disconnect the chip, keeping the power lines attached. Drop it in a reader, and you have all the decoded modules you need :D

[darkfader]

Hmz.. that's not very easy to do :)
What about loading some tiny program into memory (some OS call) before starting a real game and then trap the call and dump the memory?

[Guest]

I noticed that in the technical specs, it mentions 4 MB of DRAM. Is the other 32 MB Static RAM?

it is extremely well and authoritatively documented that the 32MB is SDRAM. You may wish to make use of the search function on pre-existing threads to educate yourself before further commenting on physical memory issues.

[tazaleth]

I believe a tool recently came out that does in fact run in kernel mode and allow one to dump memory. KDumper. It has source included. It should be available here on ps2dev, seeing as they are the ones who released it.