[U-Boot] [PATCH v2 17/18] board: Add Qualcomm Dragonboard 410C support

[Mateusz Kulikowski <mateusz.kulikowski@gmail.com>]

-----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-----