Thanks Karsten and Jean-Christian for your detailed responses! It's a complicated issue, more details below...
On 2016-10-06, Jean-Christian de Rivaz <jean-christian.deri...@innodelec.ch> wrote: > Le 06. 10. 16 à 15:26, Karsten Merker a écrit : > Right. For my curiosity I tested the netboot SD card image of the Debian > installer and tried to tell it to partition, format and install Debian > into the very same SD card the installer booted from. To my great > surprise this worked flawlessly (just need a power cycle as the reboot > simply hang). This work only with the netboot image. The hd-media > require an other partition with the ISO file making the partition/format > fail because the SD card device is busy. I don't know at this stage if > the boot stage is a residual of the image creation on the SD card or if > it was wrote by the installer. I don't believe there is any code in debian-installer to install u-boot; the installer did not install it. I don't believe there is any code within all of Debian to install u-boot automatically (unless you count SD image generation). It is at this point a manual process. >> For booting the system please see below. If that doesn't work, >> you could try running a rescue shell from the installer. Once >> you have a shell, get the following file and gunzip it: >> >> >> https://d-i.debian.org/daily-images/armhf/daily/u-boot/orangepi_plus/u-boot-sunxi-with-spl.bin.gz >> >> To write it to the eMMC, please run >> >> dd bs=1k seek=8 if=u-boot-sunxi-with-spl.bin of=/dev/YOUR_TARGET_DEVICE >> sync >> >> with YOUR_TARGET_DEVICE being the first regular (i.e. non-boot) >> eMMC partition; in your case probably /dev/mmcblk1p1. >> Unfortunately I don't know how the H3 BROM handles the >> eMMC-specific hardware boot partitions (/dev/mmcblk1boot0 and >> /dev/mmcblk1boot1), i.e. whether it tries to load the u-boot SPL >> from the first regular partition or from the first hardware boot >> partition. If the latter, this would probably need extra support >> in u-boot which to my knowledge isn't there yet. > > So I have followed this procedure: > * Reinstalled the SD card with the netboot SD card image of the Debian > installer and powered up the board. > * Interrupted U-Boot with some space characters. > * Issued the command "run bootcmd_mmc1" into U-Boot and the Debian > system on the eMMC started as expected instead of the installer on the > SD card. > * Logged as root. > * Downloaded the file with this command: wget > https://d-i.debian.org/daily-images/armhf/daily/u-boot/orangepi_plus/u-boot-sunxi-with-spl.bin.gz > * Uncompress the file with: gunzip u-boot-sunxi-with-spl.bin.gz > * Wrote the file with: dd bs=1k seek=8 if=u-boot-sunxi-with-spl.bin > of=/dev/mmcblk2 > * Issued the "sync" command. > * Removed the SD card. > * Reboot / power cycle. > * Welcome to Debian on H3 from eMMC :-) ... >> Installing u-boot from within the debian-installer can be a >> rather dangerous operation on many systems which is why the >> installer doesn't try to do that yet. The problem is that u-boot >> isn't only a bootloader like GRUB but more like a PC BIOS and >> nobody would expect the debian-installer to flash BIOS-updates on >> a PC ;-). There are quite a number of systems where writing >> u-boot to internal storage going wrong completely bricks the >> system, i.e the system is electronics garbage afterwards. Most >> sunxi-based systems still have a way to trigger SD boot or FEL >> boot as a way to manually restore the firmware, but not all of >> them do, and on many non-sunxi-platforms a broken u-boot write is >> completely unrecoverable except by unsoldering the flash or - if >> one is lucky - by accessing it via JTAG, but both are methods >> that are inaccessible for a normal user. > > I understand, but the SD card image of the Debian installer is > specifically targeted for the Orange Pi Plus board so it can take > advantage of it. While the SD card images can be used for recovery in many cases, it is also possible that u-boot installed to eMMC fails in such a way that it doesn't fall back to SD card, requiring a lot of effort to reset the board. It depends entirely on the boot ROM of the board what order it searches for the bootloader... Given that experience, I tend to strongly prefer installing u-boot on SD card when possible, as you can easily remove the SD card and reinstall a known-good u-boot from another machine. >> I'll put looking into support for installing u-boot from within >> the installer at least on certain systems onto my (unfortunately >> already way too long) todo list, but that will surely take quite >> some time. I'm also CCing Vagrant Cascadian, the Debian u-boot >> maintainer for some further input on this topic. Basically, it will require much of the same code as upgrading u-boot: https://bugs.debian.org/812611 Which has been on my todo list for quite some time with little activity. Due to the risk of bricking, both fresh installation and upgrading of u-boot should probably require some sort of opt-in process. Knowing how to install u-boot on a particular set of boards is another feature that's needed, although the SD-card image generation in debian-installer is a good start for several boards. To make matters more complicated, there are definitely some boards (Firefly, maybe BeagleBoard-X15) which can install the OS to eMMC, but u-boot still has to be loaded from SD card. I don't think we have much information on which boards those are. It may also vary from one u-boot version to the next... So, in short, there are quite a few complications to take into consideration. If someone can propose patches that take into account all these issues quite soon, it *might* be feasible for stretch. live well, vagrant
signature.asc
Description: PGP signature
