A traditional install has two medium: one source medium (dvd, cd, usb-stick) and one target medium (hard disk, ...). But here the microSD card with the image would be both the place where the install image was written, and the place of the final installation too. If debian-installer is not designed to handle that, I could check out debootstrap or similar to create a "final" setup.
The odroid HC1 is a stripped down odroid XU4, thus if the later has a device tree, it should work for both.
You are right about the blob for uboot, I had forgotten about that.
that repo has the binaries and a script to fuse them with uboot.
I suppose some ARM cpus now have microcode/firmware blobs and booting requires them?
sigh, but I suppose that is not too different from the typical intel/arm cpu with the same in the bios.
back to technical details:
if the result is just prepending before boot binary, that would be inconvenient, but easy enough to do.
So what is the next step? does debian-arm compile a uboot binary for each target plattform? a kernel?
armbian has default configs and patches for kernel/uboot in the source tree:
but that seems simple enough: uboot and kernel configs, armbian specific stuff and patches already in mainline, cherry picked for their 4.9 series IIRC, as well as overlayfs and aufs patches (not needed I suppose, unless you want to use those). Thus in summary debian with uboot and kernel configs should be good enough, I hope.
What would be good next steps? I have several of these small boards, so I can boot one with armbian and also experiment with booting one or several with debian and compare things.
If I could get debian to the point where a user running linux (e.g. desktop/amd64) could install a debian image (all free software), and then overwrite those special sectors with the cpu vendor blobs, to get a working system - that would work for me. Thoughts?
Thanks, Andreas