Flash u-boot with Easy Installer on partition different from mmcblk0boot0

Technical Support
, , ,
1

Before Easy Installer I used a ‘dd’ procedure to flash both u-boot and raw file system on my Apalis board. U-boot was flashed in mmcblk2 with “seek=2” option.

I’ve created an Easy Installer custom image where I put u-boot in mmcblk0boot0 partition (still with “seek=2” option). Not a big deal, but since we have some older systems on the field, it will lead to different update and version info retrive procedures. I hoped I could flash u-boot on the same partition to be consinstent with old releases. The problem is, u-boot written in mmcblk0 partition wan’t be recognized; looks like I need to use mmcblk0boot0 partition.

Can someone give me some hints about how to flash (and use) u-boot on different partition? And/Or why it is a bad practice to use a different partition?

This is the original JSON file

{
  "autoinstall": false,
  "config_format": 2,
  "name": "Custom Image",
  "description": "Custom Image",
  "version": "0.7.34.600",
  "release_date": "2018-09-12",
  "u_boot_env": "pri_maia",
  "prepare_script": "prepare.sh",
  "wrapup_script": "wrapup.sh",
  "marketing": "marketing.tar",
  "icon": "Logo.png",
  "supported_product_ids": [
    "0027",
    "0028",
    "0029",
    "0035"
  ],
  "blockdevs": [
    {
      "name": "mmcblk0",
      "partitions": [
        {
          "content": {
            "uncompressed_size": 1900,
            "label": "RFS",
            "filename": "rootfs.tar",
            "filesystem_type": "ext4",
            "mkfs_options": "-E nodiscard"
          },
          "partition_size_nominal": 512,
          "want_maximised": true
        }
      ]
    },
    {
      "name": "mmcblk0boot0",
      "content": {
        "filesystem_type": "raw",
        "rawfiles": [
          {
            "dd_options": "seek=2 bs=512",
            "filename": "u-boot.imx.emmc"
          }
        ]
      }
    }
  ]
}

And this is the one I used to write u-boot in mmcblk0 partition

{
  "autoinstall": false,
  "config_format": 2,
  "name": "Custom Image",
  "description": "Custom Image",
  "version": "0.7.34.600",
  "release_date": "2018-09-12",
  "u_boot_env": "pri_maia",
  "prepare_script": "prepare.sh",
  "wrapup_script": "wrapup.sh",
  "marketing": "marketing.tar",
  "icon": "Logo.png",
  "supported_product_ids": [
    "0027",
    "0028",
    "0029",
    "0035"
  ],
  "blockdevs": [
    {
      "name": "mmcblk0",
      "content": {
        "filesystem_type": "raw",
        "rawfiles": [
          {
            "dd_options": "seek=2 bs=512",
            "filename": "u-boot.imx.emmc.158b428"
          }
        ]
      },
      "partitions": [
        {
          "content": {
            "uncompressed_size": 1900,
            "label": "RFS",
            "filename": "rootfs.tar",
            "filesystem_type": "ext4",
            "mkfs_options": "-E nodiscard"
          },
          "partition_size_nominal": 512,
          "want_maximised": true
        }
      ]
    }
  ]
}

With this one, the old u-boot (loaded in mmcblk0boot0 partition) will run instead of the new one

2

Hello Massimo

What is the version of the modules you were using the dd procedure with?

For quite a long time now all modules use the eMMC fastboot mode, which means that the boot ROM looks for the boot code in the mmcblk0boot0 partition by default. This configuration is fused at the soc level, so that partition is where you should store u-boot. Some (quite old) legacy systems were not using the fastboot mode, but they are not supported by us. If you don’t have one of these rarities you might have been using the u-boot at mmcblk0boot0 when doing the dd procedure without knowing it.

3

Hi Gerard,

I don’t have the module version at hand at the moment. But I doubt those were legacy models…

Anyway, I had some issues installing a custom image via Easy Installer on the new modules (complete thread here), due to the fact that I was using an old u-boot version that wasn’t “fastboot-ready”. This old u-boot on the new board freezes after a couple of print lines (see previous link for detailed info).

I doubt that I was putting it in mmcblk0boot0 without knowing it. I was writing it with this command:

dd if=u-boot.imx.mmc of=/dev/mmcblk0 seek=2 bs=512

Since this command is not actually putting the u-boot data in mmcblk0boot0 when I use Easy Installer using the second JSON config file provided (I suppose Easy Installer is running this exact command…), I doubt it was put in mmcblk0boot0 on the old boards using the same command…

Whatever. Given your comment, looks the new boards -must- have u-boot in boot0 partition.

I can (have to?) use the same partition on my old board if I set the fastboot fuse bits? The “default” Easy Installer post install script does this. Can I run it on old boards? How? (without using Easy Installer, since I’ll update boards “on the field”).

4

Ok that was the issue then. You were using an ancient version of u-boot which doesn’t work with newer modules that come already fused with fastboot mode and use eMMC boot0 partition.

To answer your question, fastboot mode is actually independent of the partition you select for the eMMC, so in principle you could use the boot0 without changing to fastboot (see the Ext_CSD[179] command in the imx6 reference manual as well as in the JEDEC eMMC Standard). However I see no reason why you shouldn’t activate fastboot too if you can still fuse your old board.

You can indeed use the post install script from the Easy Installer to do that on old boards that have not been yet fused. Check the wrapup.sh script in any of our Easy Installer images to see the commands used. You can issue those commands directly from a linux prompt.

5

I’ll read the reference manual sections you mentioned, thanks.

Is it possible to set fastboot WITHOUT using Easy Installer? As said I don’t actually have physical access to the boards I want to update, so I can’t start Easy Installer via recovery.

6

Yes, as I mentioned, you can issue the commands directly from a linux prompt (you don’t need to do it from the Easy Installer prompt, any linux prompt is valid). There is some more documentation in our site on both fastboot and eMMC partition setting (my apologies for not having recalled that earlier). I recommend that you compare these commands with the wrapup.sh script in your current Easy Installer image, as some checks/paths/procedures may have changed.

7

You’re right, it is actually just an sh script.

The problem is, file /sys/fsl_otp/HW_OCOTP_CFG4 doesn’t exist. Neither on old and new boards. I can’t run ${BOOT_CFG} > /sys/fsl_otp/HW_OCOTP_CFG4 to set fuse bits from Linux.

EDIT

Noted that the file can be read/edited from Easy Installer. As said, I can’t run Easy Installer on on-the-field boards. I suppose it is the kernel (device tree) that is missing these definitions, so I can’t see them on the file system. Sounds right?

8

I see… Well fsl_otp is available through the CONFIG_FSL_OTP and CONFIG_FSL_OTP_WRITE kernel build options. These are set by default in our Easy Installer images only, since the Installer is supposed to handle the fusing. If you don’t have them in the old boards you will have to rebuild a linux image with this options enabled. If you have ssh access you can then update the kernel in your boards and make the fusing through the wrapup script. Remember to dd your u-boot and SPL in the the boot0 partition before rebooting.

An unadvisable alternative is using devmem2 to access the physical memory directly. This application should be already installed on your older systems. You should then check the reference manual to know exactly which registers you need to set up and their exact addresses. This option is dangerous though, as it might potentially mess up your system.