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.
