Burning/reflashing bootloader from Linux running on the board?

Products Support DragonBoard 820c
#1

Hi, we use a SD820 based SOM from a third party. We are thinking about migrating to Kernel 5.x from kernel 4.14 for the GPU temperature issue.

To boot the Kernel 5.7, it seems that we need to re-burn the bootloader. Using the flashall script, we updated the bootloader and then we were able to boot Kernel 5.7.

The question is, we would like to do what flashall does from within the Linux running on the SOM. This is because we need to provide an upgrade program to our customers and the systems at customer site don’t necessarily have USB connection needed for fastboot.
Is that possible?

Thanks,
tamo2

#2

hey,

I believe it is possible. What fastboot really does is “just”:

  1. provide a protocol to transfer raw content over USB, and the content is stored in RAM on the target
  2. write the raw content from RAM into the appropriate partition on the on board storage

So you can very much implement the same from a running Linux and write the same content into the block devices on the eMMC (/dev/mmcblk0px). Please note that since you won’t be able to implement that in an ‘atomic’ way, if the device looses power during the upgrade, you might end up with a bricked device…

1 Like
#3

Note that fastboot can burn either raw images or a sparse image (which compresses zeros and unused space). If applying this technique on other images be careful to check that any sparse images are decompressed before burning them (I don’t think the firmware files have been converted to sparse format but you could run file on them to detect the format if you have any concerns).

1 Like
#4

Thanks guys! That is a great new.

I don’t see “/dev/mmcblk0px”. Could it be because we use a 3rd party board??

How can I find the mapping between fasboot’s partitions and the Linux’s partitions?
flashall has these lines:

fastboot flash partition:0 gpt_both0.bin
…
fastboot erase ddr
…
fastboot flash cdt sbc_1.0_8096.bin

I see names “ddr” and “cdt” in rawprogram.xml but not clear how they map to partitions in Linux. And what is “partition:0”? There are “partition:0” to “partition:5” – are they related to sda…sdf?

#5

Flashing gpt_both0.bin is a special case. Repartitioning a running system is difficult because, in the general case, you have to be running everything from uSD or RAM (e.g. you’re better off running a regular partitioning tool and configuring it to achieve the same partitioning). Double check whether gpt_both0.bin has changed… if is is the same then just don’t burn it.

For other partitions they are likely links create automatically to help you. For example: find /dev -name "boot"

1 Like
#6

Right, it’s 820c, so it’s UFS, not eMMC.

If you look at the rawprogram.xml file, you will see a handful of ‘physical_partition’. Each physical_partition will correspond to a new LUN, and from Linux point of view to a ‘disk’, e.g.

LUN0 → /dev/sda
LUN1 → /dev/sdb
…

Inside each physical_partition, you have partitions, and that correspons to a partition on the ‘disk’.
e.g.
/dev/sda1, /dev/sda2
/dev/sdb1, …
…
and the partition label is the name used when flashing with fastboot.

So from the rawprogram.xml file you can derive the complete partitions on your system, and you can create the mapping you are looking for.

1 Like
#7

Why do you think you need to re-write the bootloader for this? The kernel is located at the start of the “boot” partition, along with the dtb and rootfs in android boot image format. All you need to do is generate a new boot image and “fastboot flash boot boot.img” – you can also use “fastboot boot boot.img” to test it before writing it.

#8

I don’t know the exact reason but we were able to boot 5.7 after we updated the bootloader.
I feel that the original bootloader on the SOM only handles boot image which was processed by skales/mkbootimg tool (which I assume is the Android boot image format). The new bootloader seems to be able to handle both the android format and the raw(?) format.

We tried to apply mkbootimg to the 5.7 kernel but we were unsuccessful at that time (it was a few months ago) – maybe something we can try again.

#9

Hi danielt,
Is it only gpt_both0.bin which is special because gpt_both0.bin does re-partitioning of UFS? Should we flash other similar files, such as gpt_both1.bin, … gpt_both5.bin?

It turned out that all of these gpt_both*.bin files are slightly different in binary comparison, but not flashing them seems to be OK. I am not quite sure if we should burn gpt_both1.bin…gpt_both5.bin or not.

I could not get much information about these files. The best I found was this site: [INFO] ANDROID DEVICE PARTITIONS and FILESYSTEMS | XDA Forums, which is somewhat helpful (even though we use Linux).
Do you have any other pointers, or most of them are insider only?

#10

All are special cases.

UFS media is presented to Linux as more than one storage device. Each of the storage devices needs a GPT table to describe the software partitions with in.

As far as I know all the gpt_both?.bin files contain are a GUID Partition Table (GPT). However it is easy to examine the differences if you install them on the target and examine the (software) partition using tools such as fdisk.

1 Like