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

[Vagrant Cascadian]

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-christ...@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

[Lennart Sorensen]

On Thu, Oct 06, 2016 at 12:29:13PM -0700, Vagrant Cascadian wrote:
> 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...

The BeagleBoard X15 has jumper settings to boot:

SD if present, otherwise eMMC
UART
SATA if present otherwise SD

I know the CPU for eMMC boot will boot u-boot from partition 1 with a
given filename from either FAT or EXT2 filesystem, with either MBR or
GPT partition table. It will also boot from eMMC boot area. I am
not sure which one the X15 happens to be supporting when they say boot
from eMMC.

Seems the jumpers are not installed howefver, and it would take soldering
work to make it do anything other than the first option.

--
Len Sorensen

[Jean-Christian de Rivaz]

Le 06. 10. 16 à 21:29, Vagrant Cascadian a écrit :

> 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.

And this is the only missing operation still required to fully support
Debian a board like the Orange Pi Plus.

>
>>> 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...

Not on that board. The H3 processor chip integrate a boot ROM that
always first look at the SD card and then at the eMMC (unless forced
into the special FEL mode). There is no way to break the ROM integrated
into the processor chip. Take a look at http://linux-sunxi.org/BROM for
the details.

> 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.

This is exactly how the H3 boot ROM work already. You can write anything
you want into the eMMC, there is absolutely no way to break the SD card
boot from the CPU ROM. So there is no danger in writing the bootloader
into the eMMC on that board. Writing the bootloader on the eMMC this is
exactly what a user will expect while installing Debian into the eMMC.

>
>>> 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.

From a user point of view this would be a major achievement for the
Debian armhf port that finally make some ARM boards as easy to install
than a regular PC. Well, maybe even easier than the actual UEFI PC...

Regards,
Jean-Christian

[Ben Hutchings]

On Thu, 2016-10-06 at 16:53 -0400, Lennart Sorensen wrote:
> On Thu, Oct 06, 2016 at 12:29:13PM -0700, Vagrant Cascadian wrote:
> > 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...
>
>
> The BeagleBoard X15 has jumper settings to boot:
>
> SD if present, otherwise eMMC
> UART
> SATA if present otherwise SD
>
> I know the CPU for eMMC boot will boot u-boot from partition 1 with a
> given filename from either FAT or EXT2 filesystem, with either MBR or
> GPT partition table.  It will also boot from eMMC boot area.  I am
> not sure which one the X15 happens to be supporting when they say boot
> from eMMC.

Is that actually controlled by straps, though?  For the TI SoC I've
been working with recently, when the boot device is set to eMMC the ROM
code will look for the SPL in:

1. boot area
2. fixed offsets in main area
3. file named 'MLO' in first partition (MBR, FAT)

in that order.

Ben.

> Seems the jumpers are not installed howefver, and it would take
> soldering
> work to make it do anything other than the first option.
>
>
--

Ben Hutchings
Every program is either trivial or else contains at least one bug

[Lennart Sorensen]

On Thu, Oct 06, 2016 at 11:28:07PM +0100, Ben Hutchings wrote:
> Is that actually controlled by straps, though?  For the TI SoC I've
> been working with recently, when the boot device is set to eMMC the ROM
> code will look for the SPL in:
>
> 1. boot area
> 2. fixed offsets in main area
> 3. file named 'MLO' in first partition (MBR, FAT)
>
> in that order.

When I read the documentation, that bit was rather incomplete, so I
don't know for sure. I think you are right that it tries them all.

Certainly the support for GPT and ext2 were not in the documentation
and was determined by giving it a try and being surprised it worked,
which the TI people then confirmed. So MLO can be on FAT or ext2
partition with that partition being on an MBR or GPT setup.

I prefer the boot area (and is what the product I worked on uses), with
option 3 being my second choice; I do not like option 2 at all since
it is incompatible with GPT.

--
Len Sorensen