If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I dd'd the eMMC to the sdcard, and it does boot off the sdcard. I don't know how far it boots on the sdcard until it switches over to emmc, but definitely something happens. I'm hoping that it switches over during or after aboot.

Edit... damned thing switches over *before* aboot.
Its sbl1. It boots up to sbl1 on the sdcard, then switches over to emmc.

Huh, seems that littlekernel/aboot (mmcblk0p5) is open source and builds along with CAF.

yeah.. although I think some of the early partitions have some firmware and/or trustzone/securemonitor code, which is not open.

But, I think if you leave all the partitions that preceed the boot partition, that should be safe. Sadly, trying to use gparted to resize/recreate boot partition confuses the bootloader. Somehow it isn't writing the partition table in the way that the bootloader expects. Otherwise it would be really easy ;-)

I dd'd the eMMC to the sdcard, and it does boot off the sdcard. I don't know how far it boots on the sdcard until it switches over to emmc, but definitely something happens. I'm hoping that it switches over during or after aboot.

Edit... damned thing switches over *before* aboot.
Its sbl1. It boots up to sbl1 on the sdcard, then switches over to emmc.

fwiw, one of the codeaurora guys on ##linux-msm thought that the bootloader (I think he was referring to lk) was a bit hard-coded to use eMMC. So probably the hw supports various different boot devices for the boot-rom loading the 1st stage bootloader, but then the 1st stage needs to do something other than be hard coded to load kernel/initrd off eMMC ;-)

At least that is my understanding of the situation, but I don't claim to be expert at the msm boot architecture.

fwiw, one of the codeaurora guys on ##linux-msm thought that the bootloader (I think he was referring to lk) was a bit hard-coded to use eMMC. So probably the hw supports various different boot devices for the boot-rom loading the 1st stage bootloader, but then the 1st stage needs to do something other than be hard coded to load kernel/initrd off eMMC ;-)

At least that is my understanding of the situation, but I don't claim to be expert at the msm boot architecture.

Right, its a secure chain up to and including sbl3 (aboot/lk should be free of the secure nonsense), so we can't even hexedit the bootloaders to do anything different. I'm going to wait and see what IFC comes up with, if nothing, then I'm going to try chainloading another aboot in place of the kernel. If that goes well, I'll see about a custom aboot to try hitting up the sdcard first, and then falling back to emmc.

The bootup goes PBL (that's on the 24C128 eeprom U2 between the SoC and the expansion header), then SBL1, SBL2, SBL3, and then finally LK (on the "aboot" partition), which loads the kernel. LK is the first stage in the bootup that is NOT protected by the secure/trust nonsense.

This morning I received confirmation from IFC that the LK images built with CAF Android are actually viable, and it should be possible (but obviously dangerous) to write these to the aboot partition and end up with a working system.

Now the deal with the switches, is that they say where (eMMC or uSD) to look for SBL1. SBL1 is definitely coded to at least *prefer* to find SBL2 on the eMMC. It may or may not revert to uSD if it is unable to find it on eMMC -- I can't find any confirmation of this, and unfortunately, the only way to test this would be to wipe the eMMC -- which I'm definitely not willing to try.

The good news is that LK is flexible. It is definitely capable of pulling a kernel from uSD. I'm still obviously learning LK, but there are indications that it may even fall back to uSD under certain conditions; check out lk/target/msm8960/init.c:

SDC1 is the eMMC.
SDC2 is not connected.
SDC3 is the uSD card.
SDC4 is ... wifi.

So what I'm doing now is trying to determine what conditions would be required to convince LK to pull the kernel from the sdcard, and what needs to be done to have it find it. It might be something as simple as having a gpt partition named "boot" on the sdcard while the boot partition on the eMMC is blank.

The bootup goes PBL (that's on the 24C128 eeprom U2 between the SoC and the expansion header), then SBL1, SBL2, SBL3, and then finally LK (on the "aboot" partition), which loads the kernel. LK is the first stage in the bootup that is NOT protected by the secure/trust nonsense.

This morning I received confirmation from IFC that the LK images built with CAF Android are actually viable, and it should be possible (but obviously dangerous) to write these to the aboot partition and end up with a working system.

Now the deal with the switches, is that they say where (eMMC or uSD) to look for SBL1. SBL1 is definitely coded to at least *prefer* to find SBL2 on the eMMC. It may or may not revert to uSD if it is unable to find it on eMMC -- I can't find any confirmation of this, and unfortunately, the only way to test this would be to wipe the eMMC -- which I'm definitely not willing to try.

The good news is that LK is flexible. It is definitely capable of pulling a kernel from uSD. I'm still obviously learning LK, but there are indications that it may even fall back to uSD under certain conditions; check out lk/target/msm8960/init.c:

SDC1 is the eMMC.
SDC2 is not connected.
SDC3 is the uSD card.
SDC4 is ... wifi.

So what I'm doing now is trying to determine what conditions would be required to convince LK to pull the kernel from the sdcard, and what needs to be done to have it find it. It might be something as simple as having a gpt partition named "boot" on the sdcard while the boot partition on the eMMC is blank.

cool.. keep me posted. Fwiw, 8960 is a different (older) device, compared to apq8064. (But I admit to being pretty confused by their part numbering :-P)

my main goal at the end is really just to pull kernel+initrd off a larger partition on eMMC. For filesystem, I use SATA or USB drive anyways, as that seems to perform better for doing things like recompiling stuff (like mesa), and generally be better for desktop linux filesys.

cool.. keep me posted. Fwiw, 8960 is a different (older) device, compared to apq8064. (But I admit to being pretty confused by their part numbering :-P)

my main goal at the end is really just to pull kernel+initrd off a larger partition on eMMC. For filesystem, I use SATA or USB drive anyways, as that seems to perform better for doing things like recompiling stuff (like mesa), and generally be better for desktop linux filesys.

Older? Yes and no. Older in the sense that the code was written for msm8960 "in hand", so a lot of the file names got stuck with 8960 even though they apply to both (and then some). Mainly it is just a different device. Its distinguished by having only 2 cores, Adreno 225, plus cellular connectivity (which APQ lacks).

My phone's SoC has another name again, its an 8260A (very very different from an 8260), which is basically an 8960 without LTE/CDMA. It too uses files for 8960.

When you said "Sadly, trying to use gparted to resize/recreate boot partition confuses the bootloader. Somehow it isn't writing the partition table in the way that the bootloader expects. Otherwise it would be really easy ;-)", what kind of changes did you make to the partition table? The reason I ask, is that SBL2 calls code in the TZ partition, which is positioned AFTER the boot partition. If SBL2 has a hard coded offset, it may not be able to find TZ.

What it does, is it goes through all the partitions on the eMMC, and then all the partitions on the uSD card, and adds them and their details (including names) into an array called "partition_entries".

Later on, it runs the aboot application, starting with aboot_init, which calls boot_linux_from_mmc().
Now THAT function does this;

That partition_get_index goes through the array of partitions sequentially looking for the label "boot". Since the eMMC was scanned before the uSD, its boot partition will come out first and that is the one it will favor.

Obviously for us, we would prefer it to scan the uSD first, and if it finds a boot partition there, use it, otherwise fall back to eMMC.

I believe, that renaming the boot partition on the eMMC to... anything else, would allow you to boot from an sdcard with a GPT partition named "boot". For a bit of added flexibility, renaming it to "recovery" should boot normally from the eMMC when header pin25 is held low (because it will boot from the *first* partition named "recovery").