0

I'm using dd to flash my buildroot image to an eMMC of my SBC. eMMC is connected as mass storage. The image is created with genimage and have some 'holes' in it.

genimage.cfg

image sdcard.img {
    hdimage {
    }

    partition u-boot {
        bootable = true
        image = "u-boot.bin"
        size = 2M
        in-partition-table = false
        offset = 0
        holes = {"(440; 512)"}
    }
    
    partition rootfsA {
        partition-type = 0x83
        image = "rootfs.ext2"
        offset = 3M
    }

    partition data {
        partition-type = 0x83
        image = "data.ext2"
    }
}

image data.ext2 {
    name = "data"
    ext4 {
        label = "data"
    }
    srcpath = "/home/<user>/buildroot_radxa/buildroot-2022.11/my_files/data_partition"
    size = 32MB
}
  • the writing speed is much lower that the max writing speed (around 5MB/s out of 20MB/s)
  • after dd finished I have a corrupt filesystem resulting kernel panic
  • after trying a second time, the process is finished in second with GB/s speed
  • on rare occasions it works as expected

dd command

sudo dd if=$img_path of=/dev/sdd status=progress bs=1024 conv=fsync

On the other hand I can flash the image with balenaEtcher and the system if fully operational.

What am I missing here?

mister_kanister
  • 91
  • 1
  • 7
  • It is weird the same command do not always results in the same results. Is your target device fully functional? I mean, no bad blocks, no power-loss during write, etc. – Jib Apr 19 '23 at 14:56
  • 1
    How do you convert the genimage.cfg file into a series of cluster. `dd` is dumb, it will only copy the given file into the device. It won’t interpret it. – Frédéric LOYER Apr 19 '23 at 15:02
  • @Jib This behaviour occurs with SD cards as well. Either laptop in-build SD card reader and external. @FrédéricLOYER genimages is executed in the end of the buildroot as `post-build.sh` script and creating `sdcard.img` which I then flash. – mister_kanister Apr 19 '23 at 15:09
  • which device did you boot from? – Synopsis Apr 19 '23 at 15:36
  • @Synopsis Radxa Zero v1.51, SKU: RS102-D2E8H, I'm pretty sure at this point that is has something todo with `dd` – mister_kanister Apr 20 '23 at 07:28
  • tbh, i don't think its dd. I have absolutley no clue about the stuff you are doing. thats just not in my scope of knowladge i have. but i am pretty sure that `dd` is not the actual issue. As Frederic said, `dd` is dumb. You saying that you belive that dd is messing something up, is similar to saying, that you photo copier is messing stuff up, because the copy is written in a language you dont know. Sure, there is a possibility, but its more likely, that the input file is wrong. – Malik Apr 20 '23 at 08:35
  • Quote: "On the other hand I can flash the image with balenaEtcher and the system if fully operational." ...always – mister_kanister Apr 20 '23 at 09:53
  • Did you properly eject the disk in order to flush any buffered writes? – Jib Apr 20 '23 at 10:02
  • Radxa Zero is the whole system, not the boot device :-) However, ther is way more to the procedure of booting than just roasting a static image. First, you surely have uboot still in use from emmc instead of the sd when booting. Second, the boot block contains pseudo physical data about the layout of the storage and mostly (but not only) depending on the size of emmc and sd, this layout could be different (with Etcher correcting this wrong information in the image). (to be continued) – Synopsis Apr 21 '23 at 07:32
  • Leaving aside the final target of booting from the sd, we should (as you initially mentioned) wonder about the strange write speed behaviour being highly instable. Such things result from either broken hardware (lets assume, its not broken) or varying foreign influences. As 'dd' is a well developed dump thing since decades, do not doubt its proper work. I have some things coming to my mind, that are questionable: 1.) many miniature kernels for ARM boards do strange things, so I wouldn't rely upon "fsync" and all the possible caching behind. (to be continued) – Synopsis Apr 21 '23 at 07:36
  • do a proper eject to completely remove the virtul device from the system before removing it or rebooting the board. 2.) the physical removal of the sd as well as the repeated write effort with different results IMHO clearly shows, that there's something badly wrong with whatever flushing/caching algo is "working" on that device ... resulting in the same conclusion: proper eject. – Synopsis Apr 21 '23 at 07:40
  • 3.) last but not least that (to me unknown) software "genimage" supports "holes" for the required overlapping ranges of the boot track. In case this results in creating a sparse file, I wouldwonder about how dd deals with sparse ... I never tried that, but your kernal could support it. When copying the spare to another OS "Windoze", that "sparse-ity" surely is dropped, probably increasing the filesize by 72 bytes and letting the Etcher work on something different. And: google for "what is the magic dd incantation to copy the system from the sd card to the emmc" – Synopsis Apr 21 '23 at 07:48
  • try replacing `conv=fsync` with `conv=notrunc` – droptop May 05 '23 at 16:22

1 Answers1

0

As it turns out the device has its own physical partitions on the eMMC. So to avoid the error I described, I need to clean the eMMC with U-Boot binaries provided by the manufacturer. Official doc

sudo boot-g12.py radxa-zero-erase-emmc.bin

Now I can use dd in a script.

Strange is still the write speed with balenaEtecher is higher (ca. 10MB/s) compared to dd (ca. 5MB/s). Already changed device. Tried bs=2048 and bs=4096.

mister_kanister
  • 91
  • 1
  • 7