Announcement

Collapse
No announcement yet.

MSM DRM/KMS Driver For Snapdragon Progresses

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    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:

    Code:
    static unsigned mmc_sdc_base[] =
        { MSM_SDC1_BASE, MSM_SDC2_BASE, MSM_SDC3_BASE, MSM_SDC4_BASE };
    And then later;
    Code:
    	/* Trying Slot 1 first */
    	slot = 1;
    	base_addr = mmc_sdc_base[slot - 1];
    	if (mmc_boot_main(slot, base_addr)) {
    		/* Trying Slot 3 next */
    		slot = 3;
    		base_addr = mmc_sdc_base[slot - 1];
    		if (mmc_boot_main(slot, base_addr)) {
    			dprintf(CRITICAL, "mmc init failed!");
    			ASSERT(0);
    		}
    	}
    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.

    Comment


    • #17
      Originally posted by droidhacker View Post
      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:

      Code:
      static unsigned mmc_sdc_base[] =
          { MSM_SDC1_BASE, MSM_SDC2_BASE, MSM_SDC3_BASE, MSM_SDC4_BASE };
      And then later;
      Code:
      	/* Trying Slot 1 first */
      	slot = 1;
      	base_addr = mmc_sdc_base[slot - 1];
      	if (mmc_boot_main(slot, base_addr)) {
      		/* Trying Slot 3 next */
      		slot = 3;
      		base_addr = mmc_sdc_base[slot - 1];
      		if (mmc_boot_main(slot, base_addr)) {
      			dprintf(CRITICAL, "mmc init failed!");
      			ASSERT(0);
      		}
      	}
      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.

      Comment


      • #18
        Originally posted by robclark View Post
        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.

        Comment


        • #19
          I think I understand it now.

          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;

          Code:
          	if (!boot_into_recovery) {
          		index = partition_get_index("boot");
          		ptn = partition_get_offset(index);
          		if(ptn == 0) {
          			dprintf(CRITICAL, "ERROR: No boot partition found\n");
                              return -1;
          		}
          	}
          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").
          Last edited by droidhacker; 07-24-2013, 01:40 PM.

          Comment

          Working...
          X