Hi Simon,
On 17 September 2015 at 21:54, Simon Glass sjg@chromium.org wrote:
Hi Peter,
On 9 September 2015 at 15:13, Peter Griffin peter.griffin@linaro.org
wrote:
The README had a few mistakes, and one of the URL's had changed. Also update the boot log with the latest boot trace from ATF, which now includes the mcuimage.bin.
Signed-off-by: Peter Griffin peter.griffin@linaro.org
board/hisilicon/hikey/README | 197
++++++++++++++++++++++++++++++++-----------
1 file changed, 147 insertions(+), 50 deletions(-)
diff --git a/board/hisilicon/hikey/README
b/board/hisilicon/hikey/README
index 25c8143..36adbdb 100644 --- a/board/hisilicon/hikey/README +++ b/board/hisilicon/hikey/README @@ -25,8 +25,12 @@ Currently the u-boot port supports: - Compile u-boot ==============
-make CROSS_COMPILE=aarch64-linux-gnu- hikey_config -make CROSS_COMPILE=aarch64-linux-gnu-
Do you really want the above? It seems odd that the 'cp' below expects another level of subdir.
ARM Trusted Firmware (ATF) & l-loader
@@ -34,27 +38,34 @@ ARM Trusted Firmware (ATF) & l-loader This u-boot port has been tested with l-loader, booting ATF, which
then boots
u-boot as the bl33.bin executable.
+Get the BL30 mcu binary.
https://builds.96boards.org/releases/hikey/linaro/binaries/15.05/mcuimage.bi...
- Get ATF source code
-git clone https://github.com/96boards/arm-trusted-firmware.git
-2. Compile ATF I use the makefile here
http://people.linaro.org/~peter.griffin/hikey/hikey-u-boot-release_r1/build-...
+2. Compile ATF, I use the build-tf.mak in the directory with this
README, and copy it to ATF directory
- Get l-loader
-git clone https://github.com/96boards/l-loader.git
-4. Make sym links to ATF bip / fip binaries -ln -s /home/griffinp/aarch64/bl1-hikey.bin bl1.bin -ln -s /home/griffinp/aarch64/fip-hikey.bin fip.bin
-arm-linux-gnueabihf-gcc -c -o start.o start.S -arm-linux-gnueabihf-gcc -c -o debug.o debug.S -arm-linux-gnueabihf-ld -Bstatic -Tl-loader.lds -Ttext 0xf9800800
start.o debug.o -o loader
-arm-linux-gnueabihf-objcopy -O binary loader temp +4. Make sym links to ATF bl1 / fip binaries
-python gen_loader.py -o l-loader.bin --img_loader=temp
--img_bl1=bl1.bin
-sudo bash -x generate_ptable.sh -python gen_loader.py -o ptable.img --img_prm_ptable=prm_ptable.img
--img_sec_ptable=sec_ptable.img
start.o debug.o -o loader
--img_bl1=bl1.bin
--img_prm_ptable=./prm_ptable.img --img_sec_ptable=./sec_ptable.img
These instructions are adapted from https://github.com/96boards/documentation/wiki/HiKeyUEFI @@ -62,37 +73,49 @@
https://github.com/96boards/documentation/wiki/HiKeyUEFI
FLASHING
-1. Connect jumper J2 to go into recovery mode and flash l-loader.bin
with
- fastboot using the hisi-idt.py utility
+1. Connect the second jumper on J15 BOOT SEL, to go into recovery
mode and flash l-loader.bin with
+fastboot using the hisi-idt.py utility.
-> git clone https://github.com/96boards/burn-boot.git -> sudo python /home/griffinp/Software/hikey/burn-boot/hisi-idt.py -d
/dev/ttyUSB0 --img1=/tmp/l-loader.bin
+The command below assumes HiKey enumerated as the first USB serial
port
--img1=./bin/l-loader.bin
-2. Once LED 0 comes on solid, it should be detected as a fastboot
device
- (on some boards I've found this to be unreliable)
+2. Once LED 0 comes on solid, it should be detected as a fastboot
device by plugging a USB A to mini B
- cable from your PC to the USB OTG port of HiKey (on some boards
I've found this to be unreliable).
-sudo fastboot devices
+0123456789ABCDEF fastboot
- Flash the images
-wget https://builds.96boards.org/releases/hikey/nvme.img -sudo fastboot flash ptable ptable.img -sudo fastboot flash fastboot fip.bin -sudo fastboot flash nvme nvme.img
https://builds.96boards.org/releases/hikey/linaro/binaries/latest/nvme.img
-4. Disconnect jumper J2, and reset the board and you will now
(hopefully)
+4. Disconnect second jumper on J15 BOOT SEL, and reset the board and
you will now (hopefully)
have ATF, booting u-boot from eMMC. On 'new' boards I've had to dothe
flashing twice in the past to avoid an ATF error.
- Note: To get USB host working, also disconnect the USB OTG cable
used for flashing. Otherwise you
- will get 'dwc_otg_core_host_init: Timeout!' errors.
This time I was able to make progress and build everything. My board doesn't boot past fastboot start-up but I'm going to try again in case I got something wrong. It might be worth you trying out your instructions from start to finish again just to be sure.
BTW the 2mm 1.8v UART header on the board is genius! No one would every think of that :-) It took me a month to get a special serial UART from China and then I got to practice soldering.
And this is what I did wrong. I think it's a great idea to change to UART3 though. I got it booting correctly once. Sadly I think this means that I need both UARTs connected to see what is happening with fastboot.
I think it is quite hard to figure out from the instructions is what I need to do each time I change U-Boot. IOW what is the dev cycle with U-Boot?
Once U-Boot is flashed initially, my personal development cycle is to use U-Boot to tftp a new U-Boot into RAM, and develop / iterate like that.
I only go through the rather tedious flashing process if I need to update ATF (they've added some fancy new feature like PSCI, or changed the UART), or if I wish to test that I haven't broken boot from flash before sending the series to the mailing list.
I insert the jumper and boot, hoping that 'fastboot devices' will show something. It does not. I try running hisi-idt.py. It prints 'failed' repeatedly. After a lot of trial and error I got it to work with these steps:
- build U-Boot
- make -f build-tf.bin
- insert jumper
- disconnect USB
- power board off and on
- wait for it to say 'Switch to UART download...' on UART0
- run hisi-idt.py...
- connect USB
- run ;fastboot flash fip-hikey.bin'
- remove jumper
- power board on and off
- it boots into U-Boot on UART3
I've only done this once and it is pretty tedious. Is there any shortcut please?
That is pretty much the process if you want to flash your U-Boot and ATF from a bare board.
As mentioned above I develop using USB ethernet, and tftp a new u-boot binary into RAM. Only re-flashing very occasionally. U-Boot does support the eMMC, so in theory it should be possible to flash U-Boot directly into eMMC using U-Boot, although I've never tried it myself, and don't have the commands to share I'm afraid.
regards,
Peter.
p.s. I was hoping to say hi at ELC-E in Dublin, but didn't spot you in the corridor :(