Okay. I have an idea. Let’s see what happens if we treat…<p><pre><code> 06: 00 B5 push {lr}
</code></pre>
… as the start of this weird code(?) sequence. It pushes the link register (i.e., the return address to the caller).<p><pre><code> 08: 42 40 eors r2, r0
0a: 00 2A cmp r2, #0
</code></pre>
This XORs R2 and R0 and compares the result against zero. But that’s just a decoy, as we’ll see.<p><pre><code> 0c: 00 F0 02 F8 bl #0x14
</code></pre>
This calls into…<p><pre><code> 14: 70 46 mov r0, lr
16: 00 47 bx r0
</code></pre>
… which moves the return address to R0, and then returns. Using the addresses in this disassembly (not in the actual boot ROM), the return address is 0x10; but LR and, therefore, R0 will actually contain 0x11 because the LSB signifies Thumb mode.<p>None of the previous three instructions modifies the flags. (I checked in the ARM reference manual.) Thus, “BHS” (branch unsigned higher or same) uses the flags from the “CMP R2,#0” above. _Every_ value of R2 is higher (in the unsigned sense) or same as 0. Hence, the following branch is always taken:<p><pre><code> 10: F6 D2 bhs #0
</code></pre>
… to…<p><pre><code> 00: 11 38 subs r0, #0x11
</code></pre>
R0 contained 0x11 relative to the start of this code sequence. (The absolute address in boot ROM is of course different.) Now, R0 points to the start of the code sequence.<p><pre><code> 02: C0 7A ldrb r0, [r0, #0xb]
</code></pre>
This loads the byte at offset 0xB in this code sequence. Look above, it is 0x2A.<p><pre><code> 04: 00 BD pop {pc}
</code></pre>
This returns to the caller, using the LR pushed at the beginning. The return value in R0 is 0x2A.<p>0x2A is 42 (decimal)! Could this be an Easter egg; a very obfuscated way of returning 42, the Answer to the Ultimate Question of Life, the Universe, and Everything? (Remember that the Raspberry design team is from Britain, same as Douglas Adams.)
ARM thumb disassembly:<p><pre><code> 00: 11 38 subs r0, #0x11
02: C0 7A ldrb r0, [r0, #0xb]
04: 00 BD pop {pc}
06: 00 B5 push {lr}
08: 42 40 eors r2, r0
0a: 00 2A cmp r2, #0
0c: 00 F0 02 F8 bl #0x14
10: F6 D2 bhs #0
12: 8E 46 mov lr, r1
14: 70 46 mov r0, lr
16: 00 47 bx r0
</code></pre>
Edit: I agree with the other commenters that this doesn't really look like a valid disassembly, it is perhaps data rather than code.<p>Edit2: I take that back - it's just very "creatively" written.
Direct link to the line in question:<p><a href="https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5bc007f81d7f2416b48db90f313434/bootrom/bootrom_rt0.S#L442" rel="nofollow">https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5...</a><p>(@dang, worth updating the link?)
It kind of looks like zphd is the label of the end of those bytes, right? I mean, that they are referred to somewhere else by using that as an end pointer.
Crosslinking the two posts: <a href="https://github.com/raspberrypi/pico-bootrom/issues/17" rel="nofollow">https://github.com/raspberrypi/pico-bootrom/issues/17</a>
[deleted, thought it was possibly some pre-compiled code related to the trampoline but I don't think so]<p>EDIT: I spoke too quickly, looking at the disassembly in the sibling comment.<p>EDIT 2: That disassembly looks like data, TBH.
Even if it's not obfuscated, what is this decompilation doing in the pico source repo? Are they claiming that is the real source code that someone wrote?
Lines 442-445, but apparently line numbers are stripped from GitHub URLs posted to HN: <a href="https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5bc007f81d7f2416b48db90f313434/bootrom/bootrom_rt0.S#L441-L445" rel="nofollow">https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5...</a>