U-Boot support for Dragonboard410c?

Products Support DragonBoard410c
#21

I add my modification on your dragonboard-dev branch. But it failed to boot from USB hard drive.

I tried to connect my USBtoSerial board and voltage level shifter board (convert between 3.3v and 1.8v) to pin 5 and pin 7 on dragonboard UART0. But I saw nothing in my PC. Could you recommend how to debug u-boot?

`
diff --git a/include/configs/dragonboard.h b/include/configs/dragonboard.h
index 30cfc84…4c7c60f 100644
— a/include/configs/dragonboard.h
+++ b/include/configs/dragonboard.h
@@ -83,6 +83,9 @@
#define CONFIG_USB_ETHER_MCS7830
#define CONFIG_USB_ETHER_SMSC95XX

+/File System/
+#define CONFIG_CMD_EXT4 /* EXT4 support /
+
/ Libraries */
#define CONFIG_MD5

@@ -127,7 +130,7 @@
#define CONFIG_BOOTP_BOOTFILESIZE

/* Environment - Boot*/
-#define CONFIG_BOOTDELAY -1 /* autoboot after 5 seconds /
+#define CONFIG_BOOTDELAY 5 / autoboot after 5 seconds */

#define CONFIG_SERVERIP 10.0.0.1
#define CONFIG_IPADDR 10.0.0.2
@@ -135,8 +138,8 @@
#define CONFIG_NFSBOOTCOMMAND “”
#define CONFIG_ROOTPATH “/home/nfs/dragonboard”
#define CONFIG_BOOTFILE “dragonboard/linux.itb”
-#define CONFIG_BOOTCOMMAND “usb start && tftp && usb stop && bootm”
-#define CONFIG_BOOTARGS “console=ttyMSM0,115200n8”
+#define CONFIG_BOOTCOMMAND “usb start; usb storage; ext4load usb 0:1 0x90000000 /boot/uImage; ext4load usb 0:1 0x89000000 /boot/apq8016-sbc.dtb; bootm 0x90000000 – 0x89000000”
+#define CONFIG_BOOTARGS “root=UUID=ae5fa761-95be-469b-b7dc-a355d080ed23 rw rootwait console=tty0 console=ttyMSM0,115200n8 rootfs=ext4 noinitrd selinux=0”

/* Does what recovery does */
#define REFLASH(file, part) \

#22

  • Uboot is 64bit,

  • Safest branches are dragonboard-dev/dragonboard, you can also try other but I’m updating some of them for v2 now so may be less stable (and have issue with 4.9 linaro gcc).

As for UART - I use 96boards adapter and it works flawlessly.

Does fastboot prints on your UART anything (before you start u-boot)?

Make sure it was 1.8 v converter (not 1.8v tolerant). Also - check because perhaps it needs vcc_io from dragonboard (check adapter datasheet).

As for general debugging:
easy way: uart
hard way: jtag + openocd (at least partial support is there)

If you still have a problems - please let me know.

#23

I found that it is URAT1 as serial console. I got the following message but hangs there:
…
U-Boot 2016.01-rc1-dirty (Jan 22 2016 - 11:23:01 -0500)
Qualcomm-DragonBoard 410C

DRAM: 986 MiB
MMC: msm_sdhci: 0, msm_sdhci: 1
Using default environment

In: serial
Out: serial
Err: serial
Net: Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot: 0
=>

#24

Which branch are you using?

Are you sure it’s hanged? It seems you get to u-boot console. Perhaps RX wire of dragonboard is not connected (and it doesn’t hang in fact)?

#25

I uses dragonboard-dev branch. I also have tried it with and without my USB patch.

Both it hangs in the same place in u-boot. I did saw TX LED of my USB2Serial board was blinking when I typed in keyboard. So there should be signal sent from PC.

How can you type “usb start” in u-boot if RX is not connected?

By default, if no key in, would it auto boot?

#26

My question is - is it properly wired to dragonboard as it may not receive it.
Or are you sure it’s 1.8v that you’re sending (otherwise you might have fried the pin).

If you set bootdelay to non-zero then after it reaches zero CONFIG_BOOTCOMMAND contents gets executed

#27

It is possible that there is noise in TX pin on dragonboard. Thus, it interrupts autoboot.

I have workaround: set bootdelay to zero and disable key press check. Now it can load uImage and dts from USB ext4 partition.

However, it freezes at booting kernel part. I have double check that kernel build in ext4 and usb storage.

Here is my bootcmd and bootargs:

142 #define CONFIG_BOOTCOMMAND “usb start; usb storage; ext4load usb 0:1 0x90000000 /boot/uImage; ext4load usb 0:1 0x89000000 /boot/apq8016-sbc.dtb; usb stop; bootm 0x90000000 - 0x89000000”
143 #define CONFIG_BOOTARGS “root=UUID=ae5fa761-95be-469b-b7dc-a355d080ed23 rw rootwait console=tty0 console=ttyMSM0,115200n8 rootfs=ext4 noinitrd selinux=0”

My branch:

I think it is very close. Any suggestions are appreciated.

DRAM: 986 MiB
MMC: msm_sdhci: 0, msm_sdhci: 1
Using default environment

In: serial
Out: serial
Err: serial
Net: Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot: 0 Escape CONFIG_ZERO_BOOTDELAY_CHECK: abort(0)

starting USB…
USB0: USB EHCI 1.00
scanning bus 0 for devices… 3 USB Device(s) found
scanning usb for storage devices… 1 Storage Device(s) found
scanning usb for ethernet devices… 0 Ethernet Device(s) found
Device 0: Vendor: StoreJet Rev: 0 Prod: Transcend
Type: Hard Disk
Capacity: 1907729.0 MB = 1863.0 GB (3907029168 x 512)
13886016 bytes read in 927 ms (14.3 MiB/s)
59281 bytes read in 137 ms (421.9 KiB/s)
stopping USB…

Booting kernel from Legacy Image at 90000000 …

Image Name: Dragonboard
Image Type: AArch64 Linux Kernel Image (uncompressed)
Data Size: 13885952 Bytes = 13.2 MiB
Load Address: 80080000
Entry Point: 80080000
Verifying Checksum … OK

Flattened Device Tree blob at 89000000

Booting using the fdt blob at 0x89000000
Loading Kernel Image … OK

#28

Why don’t you use default kernel / dtb load addresses - i.e. linux_addr and fdt_addr?

It seems your Linux is not booting for some reason.

Are you sure your Linux image is valid for the board (did you tried to package it into fastboot image and boot with fastboot)?

#29

I change uboot kernel/dtb load address to yours:
136 #define CONFIG_BOOTCOMMAND “ext4load mmc 1:1 0x84000000 /boot/uImage; ext4load mmc 1:1 0x83000000 /boot/apq8016-sbc.dtb; bootm 0x84000000 - 0x83000000;”

But it still failed.

I want to know where do you set your entry point address of uImage:
mkimage -A arm64 -O linux -C none -T kernel -a 0x80080000 -e 0x80080000 -n Dragonboard -d arch/arm64/boot/Image arch/arm64/boot/uImage

Yes, I confirmed that my kernel image runs fine in fastboot method. Of course, I need to copy their proprietary firmware as well.

#30

I found that if I moved to higher address. uBoot can reach further with two more line message after “Loading Kernel Image … OK”. However, it still failed. Is it possible that the loading kernel overwrite uboot memory?

`

Booting kernel from Legacy Image at 8a000000 …

Image Name: Dragonboard
Image Type: AArch64 Linux Kernel Image (uncompressed)
Data Size: 13885952 Bytes = 13.2 MiB
Load Address: 90000000
Entry Point: 90000000
Verifying Checksum … OK

Flattened Device Tree blob at 89000000

Booting using the fdt blob at 0x89000000
Loading Kernel Image … OK
Loading Device Tree to 00000000bd13e000, end 00000000bd14f790 … OK

Starting kernel …

#31

I found something related to memory location of kernel and dtb in arm64. I think I should review LK source and see how it load kernel and dtb.

https://www.kernel.org/doc/Documentation/arm64/booting.txt
2. Setup the device tree

Requirement: MANDATORY

The device tree blob (dtb) must be placed on an 8-byte boundary and must
not exceed 2 megabytes in size. Since the dtb will be mapped cacheable
using blocks of up to 2 megabytes in size, it must not be placed within
any 2M region which must be mapped with any specific attributes.

NOTE: versions prior to v4.2 also require that the DTB be placed within
the 512 MB region starting at text_offset bytes below the kernel Image.

#32

Hi;

Silly question: do you use booti? :slight_smile:

I did that mistake some time ago (and now again trying to do bootm ^^)- for armv8 devices you need to:

  1. use booti in u-boot
  2. make Image @ Linux

Then you just load it and it should work:

dragonboard410c => fatload usb 0:1 $linux_addr Image
reading Image
9492480 bytes read in 272 ms (33.3 MiB/s)
dragonboard410c => fatload usb 0:1 $fdt_addr apq8016-sbc.dtb
reading apq8016-sbc.dtb
18237 bytes read in 30 ms (592.8 KiB/s)
dragonboard410c => usb stop
stopping USB..
dragonboard410c => bootm $linux_addr - $fdt_addr
Wrong Image Format for bootm command
ERROR: can't get kernel image!
dragonboard410c => booti $linux_addr - $fdt_addr
## Flattened Device Tree blob at 83000000
   Booting using the fdt blob at 0x83000000
   Using Device Tree in place at 0000000083000000, end 000000008300773c

Starting kernel ...

Booting Linux on physical CPU 0x0
Linux version 4.4.0+ (hallor@freddy) (gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu1) ) #1 SMP PREEMPT Sun Jan 24 12:26:43 CET 2016
Boot CPU: AArch64 Processor [410fd030]
efi: Getting EFI parameters from FDT:
efi: UEFI not found.
cma: Reserved 16 MiB at 0x00000000bc800000

Sorry I forgot that but I just have single linux image for test and focus on u-boot :slight_smile:

#33

Awesome! I finally got it boot from USB hard drive now.

Thank you so much! Have a good weekend.

#34

@Mateusz

One more questions: I want to externalize boot command and environment variables into uEnv.txt in USB hard drive as Beaglebone Black so that I can change them without flashing new uBoot into MMC.

Could you advise how I can do that? Thanks in advance.

#35

Sorry for lat reply;

I would rather propose to use SD card for that case in a similar way it’s on hikey.

Something like that (depending on partitioning of your card):
#define CONFIG_ENV_IS_IN_FAT
#define FAT_ENV_INTERFACE “mmc”
#define FAT_ENV_DEVICE_AND_PART “1:1”
#define FAT_ENV_FILE “uboot.env”
#define CONFIG_FAT_WRITE

Would such solution be good enough for you or you need to use SD for something else (I have already tested that approach)?

Otherwise you must trigger probing of USB during board startup before env is probed (I would have to dig on howto do it automatically - I’m not sure if it’s easy to do).

#36

Hi Mateusz

BIG Thank You for all your efforts! I wanted to ask 2 questions…

  1. Which branch is the most recent?
    https://github.com/hallor/u-boot/tree/dragonboard-2015.11.08

  2. Does the processor’s boot loader jump to a fat partition on the sdcard and boot u-boot directly?

Cheers Bruce

#37

@Bruce:

  1. You can use dragonboard/dragonboard-dev branches - this are “old” branches used by some,
    or you can use most recent “upstream” branch - https://github.com/hallor/u-boot/commits/dragonboard-for-mainline-v2 (as of today).
    Just remember that upstream branch is quite different (for example u-boot environment is totally different).

  2. I doubt so, I’m not even sure if there are XiP-capable eMMC controllers.

In general my guess would be that ROM reads some initial startup code to something like internal SRAM and executes it, then you have few stages (bootloaders/trusted firmware/hypervisor) then Little Kernel gets executed and finally u-boot is started.

BR,
Mateusz

#38

about #2 above, the boot sequence is :

  1. ROM code starts and loads and runs SBL (1st stage bootloader) from eMMC (or SD card). It is loaded from the GPT partition called ‘sbl’. The SBL is made of 2 code segments.
    #1 is loaded in internal memory on A53
    #2 is loaded in the RPM processor memory (RPM boot code)
  2. SBL#1 will initialize DDR and load the trustzone firmware (from ‘tz’ partition), it also loads the RPM firmware from the ‘rpm’ partition.
  3. then SBL#1 loads and runs the 2nd bootloader (LK) from the ‘aboot’ partition
  4. LK will then load the ‘boot’ partition and runs it. When you use u-boot, we put it in the ‘boot’ partition, and when uboot is not used, we put the kernel image (and possibly an initrd) in the ‘boot’ image.

None of the partitions above are FAT. the firmware blob are just copied at the beginning of the partitions as raw content.

#39

hmm… I guess I need to configure my buildroot for aarch64 … pays to RTFM :slight_smile:

$ cat ./dragonboard.txt
Build & Run instructions:

  1. Install mkbootimg from git://codeaurora.org/quic/kernel/skales (15ece94f09 worked for me)
  2. Setup CROSS_COMPILE to aarch64 compiler
  3. make dragonboard_config
  4. make
#40

All working … I regret polluting this thread now, will see if I can get it cleaned up.

I added the following to my buildroot “defconfig” and now everything compiles ok

BR2_aarch64=y
BR2_ARCH_IS_64=y
BR2_ARCH_HAS_MMU_MANDATORY=y
BR2_ARCH=“aarch64”
BR2_ENDIAN=“LITTLE”
BR2_ARCH_HAS_ATOMICS=y

Bruce