[Verizon Samsung Galaxy S 4] tulth:
Okay, I went looking for the test bit. Nothing definite yet.

I found this interesting block of aboot code:

printtestbit ; CODE XREF: sub_88E15DE0+54j
seg003:88E15EAE MOV.W R0, #0xFF00
seg003:88E15EB2 LDR R1, =aTestBitD ; "TEST BIT: %d"
seg003:88E15EB4 MOVT.W R0, #0xFF
seg003:88E15EB8 BL printaboot
seg003:88E15EBC B loc_88E15E36
seg003:88E15EBE ; ---------------------------------------------------------------------------
seg003:88E15EBE
seg003:88E15EBE loc_88E15EBE ; CODE XREF: sub_88E15DE0+64j
seg003:88E15EBE MOVW R0, #0x7F7F
seg003:88E15EC2 LDR R1, =aQualcommSecu_2 ; "QUALCOMM SECUREBOOT: ENABLE"
seg003:88E15EC4 MOVT.W R0, #0x7F ; ''
seg003:88E15EC8 BL printaboot
seg003:88E15ECC B loc_88E15E6E
seg003:88E15ECE ; ---------------------------------------------------------------------------
seg003:88E15ECE
seg003:88E15ECE loc_88E15ECE ; CODE XREF: sub_88E15DE0+7Ej
seg003:88E15ECE MOV.W R0, #0xFF0000
seg003:88E15ED2 LDR R1, =aQualcommSecu_0 ; "QUALCOMM SECUREBOOT: DISABLE"
seg003:88E15ED4 BL printaboot
seg003:88E15ED8 B loc_88E15E6E
seg003:88E15EDA ; ---------------------------------------------------------------------------
seg003:88E15EDA
seg003:88E15EDA loc_88E15EDA ; CODE XREF: sub_88E15DE0+68j
seg003:88E15EDA MOVW R0, #0x7F7F
seg003:88E15EDE LDR R1, =aQualcommSecu_3 ; "QUALCOMM SECUREBOOT: T32 ENABLE"
seg003:88E15EE0 MOVT.W R0, #0x7F ; ''
seg003:88E15EE4 BL printaboot

We all knew there was a secure boot based on qfuses. But the code above indicates this "test bit" does exist on the Verizon S4, and its proximity to other secure boot operations makes me think it is related.

Now the bad news:

I'm not that great at reversing arm, and I haven't been able to trace test bit back to its source.

I searched aboot and tz and had no luck finding 0x80030.

I also searched aboot and found no reference to the 0x704xxx/0x706xxx fuses.

The fuse reads are plain as day in the primary boot loader, but I am having trouble finding them in aboot.

I thought maybe aboot talks to the TZ to read qfuses.

I found this data table in TZ that may be qfuse related

DCB 0
.data:2A027004 DCD 0x700000, 0x1BA00000, 8, 0
.data:2A027014 DCD 0x702000, 0x1BA02000, 8, 0
.data:2A027024 DCD 0x704000, 0x1BA04000, 8, 0
.data:2A027034 DCD 0x706000, 0x1BA06000, 4, 0
.data:2A027044 DCD 0x707000, 0x1BA07000, 4, 0
.data:2A027054 DCD 0x708000, 0x1BA08000, 0x3E0, 0

This table gets accessed here (in the TZ)

maybe_qfuselookup ; CODE XREF: c1_qfuse+6p
.data:2A00CAD8 ; c2_qfuse+6p
.data:2A00CAD8 MOVS R2, #1
.data:2A00CADA CMP R0, #7
.data:2A00CADC MOV R3, R0
.data:2A00CADE PUSH {R4,LR}
.data:2A00CAE0 BCS loc_2A00CB02
.data:2A00CAE2 CBZ R2, loc_2A00CB02
.data:2A00CAE4 MOV R2, #0x2A027004
.data:2A00CAEC ADD.W R0, R2, R3,LSL#4
.data:2A00CAF0 LDMIA.W R0, {R2-R4}
.data:2A00CAF4 LDR R0, [R0,#0xC]
.data:2A00CAF6 STRD.W R4, R0, [R1,#8]
.data:2A00CAFA MOVS R0, #0
.data:2A00CAFC STRD.W R2, R3, [R1]
.data:2A00CB00 POP {R4,PC

Thats as far as I've been able to take it lately. I would like to collaborate with some other developers in a git repo somewhere and concentrate effort on a particular build (IE, MDK).

---------- Post added at 08:27 AM ---------- Previous post was at 08:07 AM ----------

Follow up, i took another look and i guess after sleeping on it, things become more clear.

It looks like most of this secure boot printing stuff reads address 0x91000000 with offsets into of 0x0, 0x10, 0x20.

At least in my aboot there are several compares to 0x12345678 (i kid you not) that look like they bypass some code. Whatever that means.

Anyone know what 0x91000000 is all about?