[Hardware Hacking General] b4dg3r:
In the ARM architecture, R4 and R5 are general-purpose registers. I imagine the UART will be memory mapped.

I had a stab at interpreting the assembly below. It's been a while since I worked with ARM though so it might not be 100%

ROM:0D0002A4 ; =============== S U B R O U T I N E =======================================

ROM:0D0002A4

ROM:0D0002A4

ROM:0D0002A4 sub_D0002A4	; CODE XREF: USB_Bootloader_Download+28p

ROM:0D0002A4	STMFD SP!, {R4-R6,LR}
Store R4 through R6 and the LR onto the stack (IIRC ARM calling convention dictates that the called subroutine returns with these registers untouched). LR (Link register is the location in the calling code to jump to when this subroutine finishes)

ROM:0D0002A8	MOV R5, #0
Zero register R5

ROM:0D0002AC	MOV R0, #1
Set R0 to 1

ROM:0D0002B0	MOV R1, #0xEC000000
Load R1 with 0xEC00 0000

ROM:0D0002B4	STR R0, [R1,#0x10]
Stores the value of R0 (currently 0x01) to the address stored in R1 plus 0x10
i.e. writes 0x00000001 to 0xEC000010
Leaves R1 untouched

ROM:0D0002B8	MOV R1, #0x64 ; 'd'
Loads 0x64 (ASCII 'd') into R1

ROM:0D0002BC	MOV R0, #0
sets R0 to 0

ROM:0D0002C0	BL	USBSomething
Branches to subroutine "USBSomething".
R0-R3 might change here to values returned by USBSomething.
R4 through R11 should be untouched.
R1 (currently 0x64) and R0 (currently 0) are passed as arguments to the USBSomething subroutine

ROM:0D0002C4	ADD R5, R5, #1
Increment R5 by 1 and store in R5

ROM:0D0002C8	NOP
No-operation. Wastes a cycle.

ROM:0D0002CC

ROM:0D0002CC loc_D0002CC	; CODE XREF: sub_D0002A4:loc_D0002F8j

ROM:0D0002CC	MOV R0, #0xEC000000
Loads R0 with 0xEC00 0000

ROM:0D0002D0	LDR R4, [R0,#0x10]
Load the word at address 0xEC00 0010 into R4

ROM:0D0002D4	TST R4, #0x80000000
Checks whether the loaded word in R4 is equal to 0x8000 0000

ROM:0D0002D8	BEQ loc_D0002E4
If it is then jump to 0D0002E4 (this subroutine continues here)

ROM:0D0002DC	MOV R0, #0
If it is not, then set R0 to 0x0. By convention, R0 is used as the return value from a subroutine. So, if the word read was not 0x80000000 then the subroutine returns 0.

ROM:0D0002E0

ROM:0D0002E0 locret_D0002E0	; CODE XREF: sub_D0002A4+50j

ROM:0D0002E0	LDMFD SP!, {R4-R6,PC}
Load the previously-stored values for R4,R5,R6 and return from the subrouting (load the program counter with the link register contents stored at the start of the subroutine.

ROM:0D0002E4 ; ---------------------------------------------------------------------------
Subroutine continues here

In summary,

write 0x01 to 0xEC000010

call USBSomething with args 0x0 and 0x64

wait for one tick

Read the contents of 0xEC000010

see if it is 0x80000000

if it isn't then return 0x0 as a result to the caller

if it is then run the code after ROM:0D0002E0 LDMFD SP!, {R4-R6,PC}

TBH, I'm not convinced that the stuff at 0xEC000000 is a UART. I'd expect to see different addresses for incoming and outgoing data (probably 2x small 8-16 word FIFOs). This code reads and writes to the same location. It looks to me like it's setting a control register, doing something to do with USB and then reading the control register to see if it's in an expected state.

Edit (just found data sheet) -

According to the processor data sheet 0xEC00_0000 to 0xEC0F_FFFF is USBOTG

The register at 0xEC00_0010 is GRSTCTL (R/W Specifies the Core Reset Register 0x8000_0000)

5.8.3.5 Core Reset Register

The application uses this register to reset various hardware features inside the core.

The code is setting bit 0 "HSftRst" to 1 which soft-resets some stuff.

It then tests bit 31 AHBIdle to check if the "AHB Master State Machine is in the IDLE"

So, that doesn't look like it's anything to do with the UART.