Can I use dragonboard-410c images on a DART-SD410?

Products Support DragonBoard410c
#1

Greetings 96boards folks! My team has been evaluating the DART-SD410 by Variscite, but we’ve been having difficulty because:

  1. The pyro build instructions on the Variscite wiki, as written, do not work. (I’ve filed a half-dozen tickets about this on their support site, but I’ve not gotten much in the way of a response.)
  2. We need to run a newer kernel (4.14.15) to support one of our h/w peripherals.

I recently happened across the artifacts on this site:

A hardware engineer/colleague of mine mentioned that the carrier cards for the dragon- and dart boards conform to the same specification(?), so it should be possible, in theory, to run the images from the above site on our DART-SD410. And when I search this forum for ‘variscite’ and/or ‘dart-sd410’, there are a few hits, so… seems plausible, right?

Unfortunately, when I try to flash the 96boards boot image and rootfs to the DART-SD410 using fastboot, the system complains that it can’t find the device tree in the boot image:

[900] [900] Loading boot image (15814656): done                                                                                                            
[910] [910] use_signed_kernel=0, is_unlocked=0, is_tampered=0.
[930] [930] DTB Total entry: 1, DTB version: 3
[930] [930] ERROR: Unable to find suitable device tree for device
(247/0x00010000/0x00010018/0)
[940] [940] ERROR: Getting device tree address failed
[940] [940] ERROR: Could not do normal boot. Reverting to fastboot mode.
[950] [950] Invalid partition index
[950] [950] Invalid partition index
[950] [950] Invalid partition index
[970] [970] fastboot_init()
[970] [970] Error: ssd partition not found
[1070] [1070] USB init ept @ 0x8f697000
[1090] [1090] udc_start()
[1200] [1200] -- reset --
[1210] [1210] -- portchange --
[1300] [1300] -- reset --
[1300] [1300] -- portchange --

There seems to be some key difference in how these images are structured compared to the Variscite images. It seems—in both cases—that the boot image consists of the Linux kernel + device tree + ramdisk, but… the order of the last two items appears to be swapped in the 96boards images. We tried writing a Python script to munge the boot image so that it matched the layout of Variscite’s but this also failed to boot, with a different error message. (Sorry I don’t have that one handy to paste in here.)

Anyway, before we spend much more time wending our way down this path, can anybody confirm whether this is even possible? Or will the 96boards rocko images simply not run on the DART-SD410 without the patches mentioned in Variscite’s build instructions, or some other sit-ups?

Thanks for shedding light on this, we’ve been banging our heads on it for a couple of days now…

1 Like
#2

For reference, here’s one of the posts from this forum that implies the Variscite board should be compatible with the DragonBoard:

We’re finding that—with Yocto images, at least—they’re not interchangeable unless you ‘???’ So, yeah, that’s the question: what’s the ‘???’ step we’re missing? :thinking:

#3

Hi, I’ve been running the Linaro yocto build without patches on variscite sd410. Currently using the 18.01 release. If you want to use specific hardware on their dev kit, you might need patches to device tree.
I also tested on boards from inforce and intrinsyc , and it works on those as well.

#4

Would you mind sharing how you partitioned/flashed your Variscite board? Did you create an SD card image and flashed from there or just straight to fastboot?

1 Like
#5

Sure, no problem:

I put the device in fastboot mode, and run the flashall script from a recent rescue release: https://releases.linaro.org/96boards/dragonboard410c/linaro/rescue/latest/dragonboard410c_bootloader_emmc_linux-88.zip
Then flash your own boot and rootfs partition (actually I added that to the script as well).

The more recent Linaro releases depend on a newer bootloader than what might be preinstalled. This method also works if Android was preinstalled.

1 Like
#6

The main customisation needed to get the images to work between different SD410E boards are the bootloaders (mostly proprietary except for LittleKernel) and modification to the device tree.

Note also there are board IDs burned into the SoC itself that can cause the bootloaders to behave differently on different boards. I think this is why the DART-SD410 cannot find the DT in the original post… sounds like an old verion of LittleKernel combining with the board ID logic.

The final risk is the possibility of version skew between the bootloaders required by DB410C and the image you are loading. In other words if a board requires you to use the OEM bootloaders for some reason then there could be problems for later DB410C releases that require later bootloaders. This is a much lesser problem than it was (simply because the board is pretty mature now and the bootloaders change less frequently) but still occurs. Most of the posters above seems to be avoiding version skew with the bootloaders by using the DB410C bootloaders instead (I can’t really speculate on the effect of this… except that there are several SoM users experimenting with this approach and AFAIK no fires).

#7

Yes, actually releases/snapshots images use an ‘appended device tree’ structure, which is not supported by old bootloader versions (LK). I think it’s safe to update (as mentioned by @Thors). Check you have the ‘old’ bootloaders images in case you want to revert back.

#8

Thanks, everyone, for the detailed responses. They helped us figure out that one of the two DART-SD410 starter kits we have has a bad eMMC. Or… something. When we tried @Thors suggestion—on the other board—to download the latest rescue release and fastboot flash our own boot/root images, it Just Worked™.

We’re not sure what’s wrong with the eMMC on the ‘bad’ board. My colleague, @spini, cross-compiled MMC tools and used it to collect some diagnostics, and it didn’t detect any problems. Yet, somehow, we cannot boot from SD on that board, and fastboot is no longer starting, so… it seems we have a $300 paper weight. :expressionless:

We’ll deal with unbricking that board later, maybe. But for now, we can confirm that these images do, in fact, work fine on the DART-SD410 from Variscite—thank you!

#9

Ah yes…

The other thing that is happening right now is that it is getting hard to buy the DDR+eMMC4.5 combo parts found on the DB410C so some boards are having to switch over to eMMC5 parts instead. The resulting change of eMMC signal timings is likely to expose a latent driver bug in the upstream and LTS kernels.

Can you see any difference in board rev or package markings between the good and bad board?

#10

Since you asked… the board rev looks to be the same for both boards (v1.01). And the APQ8016E chip on both says:

QUALCOMM
APQ8016E
1VV
               DU7342LF
                UO73401

The eMMC for the working board shows these numbers:

               SEC813
               B214
               KMFNX0012M

               S67XXFMEC

The ‘bad’ board’s eMMC has the same numbers, except for the last one, which reads:

               S67XXDQ1C

(As a software developer who only occasional goes down h/w rabbit holes, these numbers don’t a mean much to me.)

The output obtained from both boards by the MMC tools utility my colleague compiled can be seen in this gist. But perhaps the diff between the two is more illuminating:

--- mmc-output-good-board.txt   2018-11-20 15:42:17.737991900 -0500
+++ mmc-output-bad-board.txt    2018-11-19 10:33:21.448973100 -0500
@@ -71,12 +71,12 @@
 Power class [POWER_CLASS: 0x00]
 High-speed interface timing [HS_TIMING: 0x02]
 Erased memory content [ERASED_MEM_CONT: 0x00]
-Boot configuration bytes [PARTITION_CONFIG: 0x00]
-Not boot enable
+Boot configuration bytes [PARTITION_CONFIG: 0x38]
+User Area Enabled for boot
 No access to boot partition
 Boot config protection [BOOT_CONFIG_PROT: 0x00]
-Boot bus Conditions [BOOT_BUS_CONDITIONS: 0x00]
-High-density erase group definition [ERASE_GROUP_DEF: 0x01]
+Boot bus Conditions [BOOT_BUS_CONDITIONS: 0x02]
+High-density erase group definition [ERASE_GROUP_DEF: 0x00]
 Boot write protection status registers [BOOT_WP_STATUS]: 0x00
 Boot Area Write protection [BOOT_WP]: 0x00
 Power ro locking: possible
@@ -132,8 +132,8 @@
 Vendor Specific Fields [VENDOR_SPECIFIC_FIELD[114]]: 0x00
 Vendor Specific Fields [VENDOR_SPECIFIC_FIELD[113]]: 0x00
 Vendor Specific Fields [VENDOR_SPECIFIC_FIELD[112]]: 0x00
-Vendor Specific Fields [VENDOR_SPECIFIC_FIELD[111]]: 0x04
-Vendor Specific Fields [VENDOR_SPECIFIC_FIELD[110]]: 0x22
+Vendor Specific Fields [VENDOR_SPECIFIC_FIELD[111]]: 0x02
+Vendor Specific Fields [VENDOR_SPECIFIC_FIELD[110]]: 0xf5
 Vendor Specific Fields [VENDOR_SPECIFIC_FIELD[109]]: 0x00
 Vendor Specific Fields [VENDOR_SPECIFIC_FIELD[108]]: 0x00
 Vendor Specific Fields [VENDOR_SPECIFIC_FIELD[107]]: 0x00
@@ -208,7 +208,7 @@
 Packed command failure index [PACKED_FAILURE_INDEX]: 0x00
 Power Off Notification [POWER_OFF_NOTIFICATION]: 0x01
 Control to turn the Cache ON/OFF [CACHE_CTRL]: 0x01
-eMMC Firmware Version:
+eMMC Firmware Version:
 eMMC Life Time Estimation A [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A]: 0x01
 eMMC Life Time Estimation B [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B]: 0x01
 eMMC Pre EOL information [EXT_CSD_PRE_EOL_INFO]: 0x01
#11

UPDATE: @spini had a support call with a Variscite engineer who confirmed that the SOM on the ‘bad’ board is, indeed, damaged somehow. I don’t have much more in the way of details, but for 60 bucks or whatever it costs, we’re planning to simply replace the SOM and be done with it.

#12

Excellent. Thanks for the update!