How to modify device tree for HC4 / µSD card speed

Single Board Computers Odroid N2/N2Plus/C4
1

Hi everybody,

the device tree for Odroid HC4 does not run the µSD card reader at the highest possible speed ( which is UHS-1 SDR104 ). Instead the dtb caps the speed to 25MByte/s.

Since the Ubuntu image provided by Hardkernel does operate the reader at full speed I decompiled the dtb files from Coreelec and Ubuntu respectively.

I already found some entries which are missing in coreelecs device tree, but now I am running into problems when it comes to switch the voltage for the reader from 3,3V to 1,8V (which is mandatory for the UHS-1 modes).

My first question is about this entry

aml_reboot {
		compatible = "aml, reboot";
		sys_reset = <0x84000009>;
		sys_poweroff = <0x84000008>;
		sd_volsw_gpio = <0x11 0x06 0x00>;
		sd_power_gpio = <0x11 0x03 0x00>;
		sd_vddio_gpio = <0x11 0x0e 0x00>;

The entries sd_volsw_gpio, sd_power_gpio and sd_vddio_gpio do not exist in the Coreelec tree. I am wondering about the meaning of the parameters and suppose that the first parameter is a phandle call ? If that is true I would have to correct this value, because phandle (0x11) in the ubuntu dts file is the same function then the phandle (0x15) in the coreelec dts file. And what is the meaning of the second and third value ?

If it would help I am able to upload the decompiled device trees for both OS.

Any hints are appreciated.

2

You need to modify the node sd_emmc_b for µSD

CE did limit it to low speed on other SoC as it’s better have 100% working with low speed than only 75% with high speed.
You will need to search around what need to be set like on Hardkernel linux sources.

3

If I interpret your answer correctly, it might be not sufficient to change something on the CoreElec dts file with a text editor and it might be neccessary to recompile the device tree from the sources ?

I found the sources from hardkernel here:

https://github.com/hardkernel/linux/tree/odroidg12-4.9.y/arch/arm64/boot/dts/amlogic)

and they are for kernel 4.9, which is correct.

Now my next question is: Is it probable that the dts source files from Hardkernel contain symbols, which could not resolved by the kernel used by CoreElec ? Or should a dts compiled from a “mix” of CoreElec and Hardkernel sources work with the CoreElec kernel ?

4

I was successful in modifying the device tree, but the results are not what I would have expected:

[    1.446098@2]- sd: new ultra high speed SDR104 SDXC card at address 59b4
[    1.446100@2]- sd: clock 199999997, 4-bit-bus-width

To achieve this I first downloaded the device tree sources and include files from Coreelec and Hardkernel. Then I send both the Coreelec and the Hardkernel dts files for the HC4 through cpp to get two big dts files with all included headers and files integrated. This made it easier to find the neccessary changes which I had to make for the Coreelec device tree. After that, I compiled the new dts file and used it as dtb.img

While the system does boot up on a cold start, it hangs on a soft reboot because it cannot communicate to the µSD card at all. And while the read speed is quite acceptable, the write speed is far too slow.

Odroid-HC4:~ # dd if=/dev/zero of=/storage/backup/testfile bs=1024k count=1024 oflag=direct
1024+0 records in
1024+0 records out
1073741824 bytes (1.0GB) copied, 549.845481 seconds, 1.9MB/s
Odroid-HC4:~ # 

Odroid-HC4:~ # /sbin/sysctl -w vm.drop_caches=3
vm.drop_caches = 3
Odroid-HC4:~ # dd if=/storage/backup/testfile of=/dev/zero bs=1024k count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.0GB) copied, 13.201482 seconds, 77.6MB/s

I will continue my tests with another µSD card and I will install an ubuntu on a SDR104 card to check this out. Limiting the speed to SDR50 in the device tree did not solve the problem.

5

Preliminary remark:

The µSD card used for the speed tests, a Samsung Pro 512GByte (2021 series) has, as I found out on the internet, a bug. This bug manifests itself in the fact that the write speed drops massively after prolonged use, while the read speed is completely normal. Fortunately, I was able to fully regenerate the card using a method recommended on the Internet, namely to write 00 bytes to it completely. I used the freeware version of the “Active@ Killdisk” program for this. Of course the card has to be partioned and formatted after that. Why for heavens sake there is no “trim” for SD cards ? :wink:

I also reactivated the petitboot bootloader in the HC4 and have now installed both Coreelec and Ubuntu on a HDD. I intentionally partitioned this HDD with GPT so that I could use enough partitions for my tests.

With this configuration, I was able to achieve the following speeds with the Samsung µSD card mentioned above:

Coreelec:

Odroid-HC4:~ # dd if=/dev/zero of=/var/media/SAMSUNG-PRO/testfile bs=1024k count=1024 oflag=direct
1024+0 records in
1024+0 records out
1073741824 bytes (1.0GB) copied, 58.881070 seconds, 17.4MB/s
Odroid-HC4:~ # dd if=/var/media/SAMSUNG-PRO/testfile of=/dev/null bs=1024k count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.0GB) copied, 13.378344 seconds, 76.5MB/s
Odroid-HC4:~ #

Ubuntu:

root@odroid:~# dd if=/dev/zero of=/media/odroid/SAMSUNG-PRO/testfile bs=1024k count=1024 oflag=direct
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 51.1421 s, 21.0 MB/s
root@odroid:~# dd if=/media/odroid/SAMSUNG-PRO/testfile of=/dev/null bs=1024k count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 13.541 s, 79.3 MB/s
root@odroid:~#

This shows that the card benefits greatly from the activated SDR104 mode when reading under both operating systems, while it remains considerably below its capabilities when writing.

For comparison:
In an USB3 card reader, which also supports the unofficial UHS-1 DDR200 mode, this card achieves 170Mbyte/s reading and 125MByte/s writing, whereby the card is formatted in FAT32 for compatibility reasons.

But there is another problem:

If I boot Coreelec directly from the µSD and then perform a soft reboot, the SD card slot is somehow “blocked” so that the card is no longer recognized and the system hangs. Only after a cold reboot it works normal again. If I do the same under Ubuntu, this does not happen. However, if I start the operating systems via the Petitboot bootloader, the soft reboot also works with Coreelec without any problems. Apparently Petitboot and Ubuntu initialize something on the card reader during the warm boot which Coreelec does not do.

Possibly this is related to three lines in the devicetree, which exist under Ubuntu but are missing in the Coreelec devicetree and which I have adopted without questioning their meaning:

	aml_reboot {
		compatible = “aml, reboot”;
		sys_reset = <0x84000009>;
		sys_poweroff = <0x84000008>;
		sd_volsw_gpio = <0x11 0x06 0x00>;
		sd_power_gpio = <0x11 0x03 0x00>;
		sd_vddio_gpio = <0x11 0x0e 0x00>;
	};

These three lines are the difference:
sd_volsw_gpio = <0x11 0x06 0x00>;
sd_power_gpio = <0x11 0x03 0x00>;
sd_vddio_gpio = <0x11 0x0e 0x00>;

Since I was too lazy to dig through the kernel resources, I don’t know what these three entries are supposed to do. Nevertheless, this is not important when booting via Petitboot, because everything works in this case.

The question remains whether it is worth activating the SDR104 mode on the compatible Odroid devices at all, but that is up to each owner of an HC4 ( and possibly a C4 ) to decide.

Enclosed for test-crazy nerds is my modified devicetree, which is only suitable for the Odroid HC4. Since the C4 is very similar, you should be able to adopt the changes after decompiling the C4 dtb to a dts file.

dtb_104.dts (67.1 KB)
dtb_104.img (57.3 KB)

If you want to give it a try then make a backup of the original dtb.img and rename dtb_104.img to dtb.img.

P.S.:

I have identified the source file containing the three lines in question, and those lines/symbols are present in the Hardkernel ubuntu sources but missing in the Coreelec sources. It is the source file reboot.c located here

and here

6

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.