Hi Casey, Thanks for the detailed review and context.
You're right — I had overlooked the fact that the default environment already defines a fastboot alias using $fastboot_addr_r, which is a safer and more flexible approach. I agree that relying on a hardcoded address like CONFIG_FASTBOOT_BUF_ADDR isn't ideal, especially considering potential overlap with LMB-managed regions.
The crash I encountered was due to the default value being 0, and this patch was intended as a quick fix to unblock fastboot functionality on QCS9100. That said, I’d be happy to look into improving fastboot to prioritize the runtime address if it's set, as you suggested. It sounds like a cleaner and more robust solution.
Best regards, Balaji On 6/30/2025 9:26 PM, Casey Connolly wrote:
fwiw since you're using the default environment (board/qualcomm/default.env) it defines an alias for the fastboot command to use a region allocated at runtime (which is tracked by U-Boot and guarunteed not to overlap with anything else). At the U-Boot prompt just do "run fastboot" to execute the alias (which expands to "fastboot -l $fastboot_addr_r usb 0") Ideally we would get rid of this workaround and instead teach fastboot to prioritise the runtime address from that variable if it's set. Hard-coding the address like this could cause issues if it happens to overlap with some LMB allocated region. If you have the cycles free to fix it properly I would be very greatful, but I'm happy to take this in the meantime.
