On Thu, Nov 17, 2016 at 04:25:14AM -0500, Ian Sutton wrote: > (resending as list seemed to eat my last mail) > > Hi, > > I've got a natively-built bootloader working on the pine64 boards > generously donated to the foundation. Simply dd(1) the following image > directly to a uSD card, insert it, reset the pine64, and you will be > greeted by a u-boot prompt over the serial terminal: > > https://ce.gl/pine64-uboot-openbsd.img > > To provide a better understanding of what's going on here, I've devised > a tarball that (attempts) to build such an image, found here: > > http://ce.gl/pine64-openbsd-bootloader-tool.tgz > > Note -- I cobbled this together pretty quickly just as a > proof-of-concept: there will likely be mundane bugs in the Makefile > > In the above tarball, there are a few important items: > > - gcc aarch64 cross-tools & binutils, from patrick@'s excellent patch > > - modified u-boot port, also patrick > > - boot0img, small tool, generates final image > > - ARM trusted firmware tool, generates board-specific firmware binaries > used early-on in the boot process. It informs the hardware logic > where the u-boot binary lives, how big it is, what its checksum is, > etc. > > - boot0.bin, the (I think) very first bit of code executed at power-on > time. I stripped this from around the top of the vendor-provided boot > images. i sure hope it is legally distributable > > I suggest editing the makefile and setting -j8 or similar flags on the > lines that build u-boot and the aarch64-none-elf tools as they take an > insanely long amount of time. > > Similar to most ARM boards, the boot process on the pine64 is not at all > trivial -- about 5 discrete bodies of code that could be construed as > 'bootloaders' exist between the power jack & userspace. To the best of > my understanding, the process is as follows: > > 1.) at power-on, hardware logic checks for presence of boot media (in > our case only uSD card). If no card is inserted, hardware falls back > to some arcane USB boot/firmware upgrade mode we don't care about > > 2.) hardware logic seeks to ~0x2000 and reads a few KB from uSD card > and writes it to on-silicon SRAM. > > 3.) boot0.img code gleans hints about the "real" bootloader, u-boot, > such that it can safely load an image. I don't know if it's loaded > to DRAM or SRAM; something here happens that involves trampolining > which I do not understand. Ostensibly the ARM trusted firmware code > runs around here, checksumming the purported u-boot image and > comparing it against the sum written near the top of the "disk"
The proposed patches to implement SPL support for A64 have not been merged to the main u-boot repository yet. The SPL support does what the closed boot0 did. http://lists.denx.de/pipermail/u-boot/2016-November/271722.html ATF runs in trustzone and persists to implement PSCI. And of course you'd have to jump back to 32 bit to actually run the kernel.
