Changes to support booti u-boot command

[siddharthtuli_gmail.com]

Summary

Mark the physical memory region where the initrd image is loaded using booti U-Boot command as an excluded region. Use pmap_kenter to map it to virtual memory.
Map the 1GiB aligned physical load address of FDT blob passed from booti as an L1 block page table entry (so that is mapped PA = VA).
Use "FreeBSD:" string as a guard at the start of bootargs passed from U-Boot to indicate that they are for FreeBSD.
vmcore generated when kernel.bin is used are not debug-able by gdb. Remove LINUX_BOOT_ABI from GENERIC arm64 config untill this is resolved.

[mmel]

With full respect, I have no idea why you want/need these changes to original D13861.
Adding initrd support to top of D13861 is simple (we can use fragments from this patch).
For me most clean way how to solve this situation is:

1. revert original commit.
2. commit D13861 (without putting LINUX_BOOT_ABI to GENERIC)
3. convert this patch to adding initrd support on top of D13861 ( I offering full help for this)
4. fix generation of booti image (by utility program or by some hex editing, having booti header in locore.s is not a right way)

I'm, of course, open to any other rational solution.

sys/arm64/arm64/locore.S

378

This test seems misleading and incomplete.
You cannot expect that KERNBASE (VM_MIN_KERNEL_ADDRESS) can be used as mask

(whats happen if someone move it to 0xffff001... for example).

imo, we should ' x0 > VM_MIN_KERNEL_ADDRESS && x0 < VM_MAX_KERNEL_ADDRESS". But, original test used in D13861 looks much more robust for me.

451

This is clearly wrong wrong because x0 can be NULL at this point

456

current locore.S (after ASID change) uses 'ATTR_nG | TTR_IDX(NORMAL_UNCACHED)'
for identity mapping. We should use same attribute.

sys/arm64/arm64/machdep.c

1074

Again, this test is not right. Moreover, both tests should be consistent (KERNBASE vs. VM_MIN_KERNEL_ADDRESS)

sys/arm64/arm64/machdep_boot.c

111

You have removed loading of symbol table to DDB. Why? Please put this code back.

125

Who initialize static kenv if u-boot doesn't provide valid command line?

148

this test is wrong. We may have backup static copy of dtb compiled in kernel but other (updated) dtb can be passed to kernel by u-boot. FDT_DTB_STATIC is not mutually exclusive with LINUX_BOOT_ABI.

sys/arm64/arm64/pmap.c

982

use SYSINIT() machinery to do this.

[siddharthtuli_gmail.com]

Hi Mmel,

In D22499#493239, @mmel wrote:

With full respect, I have no idea why you want/need these changes to original D13861.
Adding initrd support to top of D13861 is simple (we can use fragments from this patch).
For me most clean way how to solve this situation is:

1. revert original commit.
2. commit D13861 (without putting LINUX_BOOT_ABI to GENERIC)
3. convert this patch to adding initrd support on top of D13861 ( I offering full help for this)
4. fix generation of booti image (by utility program or by some hex editing, having booti header in locore.s is not a right way)

Thanks for the valuable comments and for providing details on handing initrd arg of booti. The suggested approach sounds good.

sys/arm64/arm64/locore.S

451

Please pardon my ignorance, but atleast I could compile with FDT_DTS_FILE and FDT_DTB_STATIC options and I could boot kernel with booti.
booti <kernel loadaddr> <== x0 would be zero in this case

456

Sure. Thanks.

sys/arm64/arm64/machdep_boot.c

111

It appears that MAGIC_TRAMP_NUMBER is not defined for arm64. This was resulting compilation error.

125

Please pardon. I should have used init_static_kenv(NULL, 0).

148

Thanks for this information.

sys/arm64/arm64/pmap.c

982

Sure. Thanks.