On 2016-10-31, Adam Borowski wrote: > Could you please provide some docs how to use this package to install/update > on an existing system? Documentation currently provided is pointless:
It is, admittedly, quite confusing. The process for pine64 is more complicated than most boards. Various parts bounce back and forth between 32-bit and 64-bit during the boot process... I think the technical term is "trampoline". This might be a little better description of the process, if only because it breaks the various parts out a little more clearly: https://github.com/apritzel/pine64/blob/master/README.md > * it describes how to cross-compile from sources, despite this being a > compiled package The various steps described in the README.pine64 can be run natively or using a cross-compiler. The u-boot package provides the u-boot.bin, so you obviously don't need to build that. You still need to compile ATF from source, built for arm64: https://github.com/apritzel/arm-trusted-firmware.git You need to build the boot0img code for whatever architecture you're building/updating the image from. A boot0.img from a working pine64 system image needs to dumped. > * it describes how to do that from another host, despite the package being > available only on :arm64 (ie, natively) Are you aware that multi-arch allows installing foreign-architecture packages? https://wiki.debian.org/Multiarch/HOWTO > * assumes building a new image, nuking the existing system. One could > manually copy parts before the first partition but that's error-prone > and undocumented (which bits of sector 0 should be copied and which not? > what if the first partition's start differs?) You need to leave at least the first 20MB of your SD card free, so the first partition needs to start after that. The boot0img tool has options to update rather than overwrite the image. You could read the boot0img source code if you really wanted to do it manually and produce documentation from that... but like you say, that would be very error prone. > Docs I find elsewhere seem to assume pre-existing knowledge of u-boot. I > for one had written boot menus and boot infectors in the previous millenium, > yet, being completely ignorant about u-boot, can't figure it out. Thus, > some docs for dummies would be great. At this time, it *is* a process that requires complicated steps, and moreso than most boards I've worked with. Some of those such as dumping the boot0.img from an existing image will go away when pine64 u-boot gets native SPL support (e.g. early stage bootloader), which is a work-in-progress. But some of them are due to hardware design. > Or perhaps I'm missing some nice command that takes Debian kernel packages > (either the official ones (no pine64 support yet) or ones produced by "make > bindeb-pkg") -- ie, with /boot/vmlinuz-$KVER instead of Image, *.dtb in > /usr/lib/linux-image-$KVER/allwinner/, putting all the gubbins in the right > places without user intervention? I don't think it exists, so you're not missing anything that everyone else isn't already missing. Once the support for pine64 is in the mainline kernel, we can add appropriate boot scripts to the flash-kernel package. The bootloader installation will still likely remain a bit of a manual process. > We have this comfort on other archs... Welcome to the uncomfortable world of arm! So, while I'm sure it still leaves a lot of open questions, hopefully that helps a bit... live well, vagrant
signature.asc
Description: PGP signature
