January 9, 2017

Orange Pi Plus - U-boot on the eMMC

After a bit of study, I find there is a specific U-boot build for the Orange Pi PC Plus. Note also that the Orange Pi Plus is not the same as the "PC Plus" and we are working with the latter. So we rebuild U-Boot using the v2016.11 sources with the Armbian patches. 
cd u-boot
export CROSS_COMPILE=arm-linux-gnu-
make distclean
make orangepi_pc_plus_defconfig
make all
This runs quickly, giving me a binary file. I boot my PC Plus using an Armbian image, copy the binary to it using scp and then install it onto eMMC using: 
dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblk1 bs=1024 seek=8
447+1 records in
447+1 records out
458738 bytes (459 kB) copied, 0.0609168 s, 7.5 MB/s
Now we get this: 
U-Boot SPL 2016.11-g29e0cfb-dirty (Jan 09 2017 - 11:19:55)
DRAM: 1024 MiB
Trying to boot from MMC2


U-Boot 2016.11-g29e0cfb-dirty (Jan 09 2017 - 11:19:55 -0700) Allwinner Technology

CPU:   Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi PC Plus
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 1, SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   phy interface0
eth0: ethernet@1c30000
Hit any key to stop autoboot:  0 
** File not found /boot/boot.bmp **
** Unrecognized filesystem type **
There is no valid bmp file at the given address
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
MMC: no card present
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
USB4:   USB EHCI 1.00
USB5:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
scanning bus 4 for devices... 1 USB Device(s) found

USB device 0: unknown device
BOOTP broadcast 1
DHCP client bound to address 192.168.0.60 (9 ms)
*** Warning: no boot file name; using 'C0A8003C.img'
Using ethernet@1c30000 device
TFTP from server 192.168.0.1; our IP address is 192.168.0.60
Filename 'C0A8003C.img'.
Load address: 0x42000000
For some reason the keyboard does not interrupt the autoboot as it should, but I find typing Control-C a bunch of times while it is trying to do TFTP ultimately places me at the U-Boot prompt. Then I can make and save the environment changes to do network booting as I want to.

First I note the value of this variable (which I am going to change) in case I ever want to go back to the default: 

printenv bootcmd
bootcmd=run loadsplash; run distro_bootcmd
I first did the following, which works, but "wires" too much stuff into the U-boot environment. It is better to let this stuff be fetched via dhcp (but this would be the way to do things if you didn't have a DHCP server set up). See below for the simpler DHCP setup. 
setenv serverip 192.168.0.5
setenv ipaddr 192.168.0.60
setenv bootfile orange.bin
setenv bootaddr 0x42000000
setenv boot_kyu echo Booting via tftp (\${bootfile})\; tftpboot \${bootaddr} \${bootfile}\; go \${bootaddr}
setenv bootcmd run boot_kyu
saveenv
Note all the backslashes in the definition of "boot_kyu". These are essential for two reasons. One is that without escaping the ";" it thinks you are defining something, then going on to issue the tftpboot command right then. Second is that without escaping the "$" it will interpolate the current values for bootaddr and bootfile at the time of definition, rather than defering them until later as I would like.

When I do this, it tells me: 

Saving Environment to MMC...
Writing to MMC(0)... done
The following works great and gets all of the boot information from the DHCP server: 
setenv bootaddr 0x42000000
setenv boot_kyu echo Booting Kyu via dhcp/tftp\; dhcp\; go \${bootaddr}
setenv bootcmd run boot_kyu
saveenv

Have any comments? Questions? Drop me a line!

Tom's electronics pages / tom@mmto.org