Hi Drew, On 2024-12-18 4:13 AM, Andrew Jones wrote: > On Mon, Dec 09, 2024 at 10:44:40PM -0600, Samuel Holland wrote: >> This allows flat binaries to be understood by U-Boot's booti command and >> its PXE boot flow. >> >> Signed-off-by: Samuel Holland <samuel.holland@xxxxxxxxxx> >> --- >> riscv/cstart.S | 16 +++++++++++++++- >> 1 file changed, 15 insertions(+), 1 deletion(-) >> >> diff --git a/riscv/cstart.S b/riscv/cstart.S >> index b7ee9b9c..106737a1 100644 >> --- a/riscv/cstart.S >> +++ b/riscv/cstart.S >> @@ -39,15 +39,29 @@ >> * The hartid of the current core is in a0 >> * The address of the devicetree is in a1 >> * >> - * See Linux kernel doc Documentation/riscv/boot.rst >> + * See Linux kernel doc Documentation/arch/riscv/boot.rst and >> + * Documentation/arch/riscv/boot-image-header.rst >> */ >> .global start >> start: >> + j 1f >> + .balign 8 >> + .dword 0 // text offset > > When I added a header like this for the bpi I needed the text offset to be > 0x200000, like Linux has it. Did you do something to avoid that? It turns out that U-Boot on my board is configured to ignore the first 0x200000 bytes of DRAM entirely, so the binary ended up at the right address for the wrong reason. I can send a v2 with this field changed to 0x200000 (which also works on my board). Regards, Samuel >> + .dword stacktop - ImageBase // image size >> + .dword 0 // flags >> + .word (0 << 16 | 2 << 0) // version >> + .word 0 // res1 >> + .dword 0 // res2 >> + .ascii "RISCV\0\0\0" // magic >> + .ascii "RSC\x05" // magic2 >> + .word 0 // res3 >> + >> /* >> * Stash the hartid in scratch and shift the dtb address into a0. >> * thread_info_init() will later promote scratch to point at thread >> * local storage. >> */ >> +1: >> csrw CSR_SSCRATCH, a0 >> mv a0, a1 >> >> -- >> 2.39.3 (Apple Git-146) >> > > Thanks, > drew
