6.18 ships lan9696-ev23x71a.dts but does not document microchip,ev23x71a
in the AT91 binding, so dtbs_check has nothing to validate the board
against.  Take the upstream commit that adds it.

Signed-off-by: Joachim Wiberg <troglobit@gmail.com>

The part number decides whether the driver offers PTP and PSFP, and it
is the only thing that tells two otherwise identical Laguna boards
apart, so it is worth having before Linux is up.

Trim the prose while here: a handful of sentences that set the scene
before getting to the point, and one comma splice.

Signed-off-by: Joachim Wiberg <troglobit@gmail.com>

Infix netboots from rootfs.itb alone: the bootloader maps the SquashFS
inside it and runs sysboot, which picks the kernel and device tree out of
/boot.  That needs BLKMAP, SquashFS, and sysboot, which our own U-Boot
gets from board/common/uboot/extras.config.  The Tactical 1000 ships a
vendor U-Boot with none of the three, and we cannot replace it until
Novarq tell us how VCORE[3:0] is strapped, so there is no way back from a
bad FIP.

Pack the kernel, the device tree, and the root filesystem into one FIT
instead, which that bootloader can start with a single bootm.  Enabled by
default when a board that needs it is, and unsigned: nothing that needs
this image can check a signature, and the verified path is still
rootfs.itb by way of sysboot.

The device tree gets a load address rather than being left where mkimage
packed it.  U-Boot grows the tree in place to add the kernel command line
and the ramdisk bounds, and inside the image that growth lands on the
ramdisk behind it.  The kernel is then handed a tree it cannot parse and
dies before earlycon, with nothing on the console to say why.

A boot script comes with it, to hand out as the DHCP boot file so a test
system needs no typing at the prompt.  It takes the image name from
${bootfile}, so it finds whatever sits beside it on the server, and reads
the root filesystem size out of the FIT rather than having it built in.

Signed-off-by: Joachim Wiberg <troglobit@gmail.com>

First boot after a factory reset does not enter the regular code path
because factory-config essentially becomes the startup-config.  So it
left the status LED blinking.

Follow-up to a7c95cd.

Signed-off-by: Joachim Wiberg <troglobit@gmail.com>

One configuration per device tree in the build, named after it, so the
same image boots any board with bootm <addr>#<board>.  The board this
build was configured for stays behind 'boot', which the boot script uses,
so nothing about the tested path changes.

The kernel is gzipped, three to one, and the data is external with each
blob on a 4 KiB boundary, as rootfs.itb has it.  Not at a fixed offset,
though: with a configuration per board the header outgrows the 4 KiB
rootfs.itb reserves, and mkimage places the data after it either way.

The device trees go last.  U-Boot grows the selected tree in place to add
the kernel command line and the ramdisk bounds, and packed ahead of the
ramdisk that growth overruns it.  After the ramdisk it only ever reaches
another board's tree.  The default board's tree keeps a load address of
its own as well, since that is the path that has been booted.

This is what the removed mkfit.sh did, refactored into the image package
its removal asked for, and reading the device trees from the target tree
rather than from images/, which is where it broke.

Signed-off-by: Joachim Wiberg <troglobit@gmail.com>

The root filesystem carries the kernel in /boot for the bootloaders that
read it from there.  boot.itb already has it, so drop the copy, 13 MiB
compressed, or about a twelfth of the image.

Done under fakeroot so ownership survives the round trip, and with the
block size and compression read off the rootfs itself so it matches
whatever the build used.  It is a knob, on by default: it costs an
unsquash and resquash of the rootfs on every build, and the rootfs that
boots is then not byte for byte the one in rootfs.itb.

Signed-off-by: Joachim Wiberg <troglobit@gmail.com>