-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Daniel,
Thanks for the hints! On 12.03.2016 00:58, Daniel Glöckner wrote: > On Sun, Feb 07, 2016 at 09:57:37PM +0100, Mateusz Kulikowski wrote: [...] >> +.global _fastboot_header >> +_fastboot_header: >> + b _start >> + add x13, x18, #0x16 >> + /* Image load offset from start of RAM, little-endian */ >> + .quad CONFIG_SYS_TEXT_BASE-PHYS_SDRAM_1 >> + /* Effective size of kernel image, little-endian */ >> + .quad 0 /* 0x60000 */ >> + /* Informative flags, little-endian */ >> + .quad 0 >> + .quad 0 /* reserved */ >> + .quad 0 /* reserved */ >> + .quad 0 /* reserved */ >> + .byte 0x41 /* Magic number, "ARM\x64" */ >> + .byte 0x52 >> + .byte 0x4d >> + .byte 0x64 >> + .word 0 /* reserved */ > > I don't think fastboot is the correct term to use here. The structure in > head.S is the ARM64 Linux kernel header described in section 4 of this > document: https://www.kernel.org/doc/Documentation/arm64/booting.txt > Fastboot is AFAIK a USB protocol spoken by bootloaders used on Android > devices. Little Kernel can do fastboot, but it doesn't do it to run this > image. Good point, in that case I'll just rename it to arm64_header :) > > It is also confusing to have the "add" instruction in there without an > explanation, especially because having it at offset 4 instead of 0 defeats > its original purpose (MZ EXE signature for EFI). My bad, I should have put it the other way around: add x13, x18, #0x16, b _start Will do that for v3 > >> +6) generate qualcomm device tree, use dtbTool to generate it >> +$ dtbTool -o dt.img arch/arm/dts >> + >> +7) generate image with mkbootimg: >> +$ mkbootimg --kernel=u-boot-dtb.bin --output=u-boot.img --dt=dt.img >> --pagesize 2048 --base 0x80000000 --ramdisk=rd --cmdline="" > > I would have liked a bit more text about what is done with the device > trees here. Little Kernel refuses to run the "kernel" unless it can > find a device tree matching the hardware it is running on. It adds some > information to the device tree and passes it to the kernel in the x0 > register. U-Boot discards the contents of the x0 register and uses the > device tree appended to its image. So there is no need to point dtbTool > to the same dtb file used by U-Boot. A smaller one containing only the > IDs checked by Little Kernel would be enough. And dtbTool does not > generate a device tree, it generates the Qualcomm device tree table > containing all dtb files in the directory. I'll clarify readme, thanks for verbose explanation. I know (almost) empty dtb is enough (I use it personally), but I didn't wanted to pollute dts directory with fake device trees. > I know the goal is to eventually replace Little Kernel, but how about > using the device tree passed by it? We could add some code to head.S that > saves x0 in sp_el0 and abuse CONFIG_OF_HOSTFILE to retrieve it. I prefer not to (at least for now) - It will not give us significant benefits (image will be a bit smaller and boot slightly faster, but it's not an issue as U-Boot replaces huge kernel image) and will just confuse people that already are using it. Is it fine with you? Regards, Mateusz -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW5IZ7AAoJELvtohmVtQzBjj0IAJMwf9zutegyq5bmzG5ZYYJW dcdqRUXXDDV5IocWDxYK1BGALoFocxxqkRaimwT04r+0ZZ4SsLKXnmKkGJcwSE6p VfWW3aXG437VlVTDwyo8idSRESrFXkjtdrke+4xDQxoFWlCfUifKJJ53NYH2AzYt lj/ZDvuGikAJPDN27DeITlJVqq1OXcOTXfJbooIMGqTFbt/R8bZb1dIP/wF6GobS OqivQcMPh12pKped7Ym1kWMWJ01CWiauePjSK4xRJyAvZUjbvzke/8joBcpHDpaw IGMR5g1RNN6d9flV/W25Ryzrz5XS9M5+ikqucBnSkQD/POnvhHKOkPL9SdMHeYY= =zhqu -----END PGP SIGNATURE----- _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
