[PROJECT] /cache as RAM

We really need to pull our bootloaders and decomplile them to see if there's a way to do the fastboot ourselves. The people that have looked the hardest at the bootloader are on Milestone A853, but according to them they don't have a working "fastboot boot" so that code pathway is missing from their studies.

What we need to find out is what the pathway through the bootloader is that ends up with booting a custom boot.img from RAM (i.e. does fastboot boot go through the entire boot stack or not and if it does how does it convince it to skip the check). In other words I have two mental two models for how fastboot works:

Model 1

1. Start boot process
2. Read flags that direct boot to fastboot
3. Load and execute fastboot bootloader
4. fastboot reads kernel from USB into memory
5. fastboot continues boot using the kernel in memory

Model 2

1. Start boot process
2. Read flags that direct boot to fastboot
3. Load and execute fastboot bootloader
4. fastboot reads kernel from USB into memory
5. fastboot sets up the phone for boot of the memory-loaded kernel
6. fastboot restarts boot process
7. Read flags that direct boot to load and execute the kernel from RAM

So the question is which one is correct? Does fastboot boot continue the current boot process, or does it alter the next boot? That's the big question. If it's model 2, here's an outline for a possible attack:

Attack for Model 2

1. Normal boot of blessed kernel through sh_hijack.sh
2. hijack loads a new kernel from the phone into memory
3. hijack sets up the phone for boot of the memory-loaded kernel
4. hijack set boot flags for fastboot boot
5. hijack restarts boot process
6. Boot memory loaded kernel

So how do we figure out if XT720 uses #1 or #2?

FYI: these are the A853 decompiled bootloaders: https://gitorious.org/droid/reversed (see the asm folder inside the source tree--we need this for XT720 so that we can understand what fastboot boot is doing)

hellmonger said:

I was looking into the exact samething but once bootloader is loaded how do we get the OS to load the Kernel?

I thought nothing was running exept fast boot at that stage...

Click to expand...

Click to collapse

That gets down to my question: how does fastboot boot the kernel? Does it set some flags and reboot?

Here's what I mean: The bootloader decides where it's going at boot. i.e. at least one of these options (a) normal boot, (b) boot to recovery or (c) bootloader or (d) fastboot bootloader. Is there another one: (e) boot the kernel that's already in memory?

One way you can tell the bootloader where you want to go is by pressing buttons. But there is obviously another way--you can boot into recovery (I'm talking about the motorola recovery here--openrecovery is a normal boot from the bootloader's perspective) without holding buttons. When you do type something like "reboot bootloader" and "reboot recovery" or use the power menu in Android to do that somehow the bootloader is being told what to do. It does this by saving state outside of the filesystem somewhere. As you've been combing through your logcats you may have seen:
I think that's an example of this sort of communication. More evidence for this sort of thing: when you run the command "reboot bootloader" or "reboot recovery" the strings "bootloader" and "recovery" are passed to the kernel via the __reboot() function. The kernel saves that information somewhere. On next boot the bootloader reads that state and goes where it's been asked to go. So this external pathway for talking to the bootloader between reboots exists. Reboot to recovery or bootloader boils down to calling:

__reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_RESTART2, "recovery");
__reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_RESTART2, "bootloader");

These go into kernel/sys.c of the linux kernel and I think these then filter into architecture-dependent code inside e.g. arch/arm/mach-omap2/board-sholest.c etc and gets written to the GPIO's and stored for the bootloader to read at next boot.

The question is does "fastboot boot" also use something like that to signal for the bootloader to not load anything into memory and to just trust and boot the kernel that's already made it into memory? I have a hunch this is a good guess from an engineering perspecitve. If you don't do as close to a real reboot into the new fastbooted kernel as possible you run the risk of introducing new unexpected bugs. That's why I think there's a slight chance that "Model 2" may be what actually exists and it's using some sort of GPIO signal or whatever to tell the bootloader to skip the signature checks and boot a kernel that's already in memory.

LOL no ideas huh.....

Me either.... i wont give up tho i know for sure there is a way...

fjfalcon said:

kernel dont have swap support, so you can't use it from kernel layer. maybe you may find some swap functions in dalvik virtual machine layer, but I don't sure is there any

Click to expand...

Click to collapse

still no luck...

my goal is to stop the whole fastbot thing and use that cache partition as RAM, i already know how to set the download cache directory to SD card

on my ROM it's already implemented...

/cache as Ram.....

mchlbenner said:

I believe a 2nd had beem complied but it would not boot radio and we don't have a baseband made.

Click to expand...

Click to collapse

This would be different from 2nd-boot. Despite the name, 2nd-boot doesn't use a second boot. 2nd-boot tries to replace a running kernel with new one. The idea here is to just automate the fastboot boot we already use (which may or may not be possible).