[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Install on Orange Pi Plus eMMC work but no reboot

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.derivaz@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:


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,

Attachment: signature.asc
Description: PGP signature

Reply to: