On 2018-08-12, Jan Kiszka <jan.kis...@web.de> wrote: > am I right that the u-boot.bin from the buster package u-boot-mvebu is > not for direct consumption by the ESPRESSObin?
You are right. > All documents I found say that it has to be embedded into an ATF > module, forming the final SPI flash content. Yes. It's one of the more convoluted processes I've seen: http://wiki.espressobin.net/tiki-index.php?page=Build+From+Source+-+Bootloader But instead use the mainline/debian packaged u-boot, and experimented with the parameters passed to make when building the vendor ATF to try and get a working ram configuration. And of course the documentation is a bit dated from the actual source code. I found it pretty tedious and error-prone. It also happens to be backwards from several other platforms I've seen (e.g. allwinner), where the build process is build ATF, build u-boot (which incorporates ATF), and also happens to be possible to build the various pieces independently of their respective build processes and assemble a bootable image out of the various parts (e.g. u-boot-install-sunxi64). > Is there anything along this line packaged already? Not to my knowledge. It looks like upstream ATF has support for a3700, so might also be possible to package this. But it seems to require a different build for each ram configuration, which is... an unfortunate number of permutations. And also requires embedding u-boot at ATF build-time... I haven't figured out how to properly packages A3700-tools, which seems to also be built as part of the build process. > what is the purpose/plan for this u-boot package? To at least reduce the number of things the end-user has to build. Unfortunately, I haven't had luck getting mainline u-boot to recognize more than 512MB of ram. Since the process is a little ugly and poorly documented, I've debated removing this target from buster... help in improving the situation would be greatly appreciated! live well, vagrant
signature.asc
Description: PGP signature