How to replace u-boot only on a Colibri iMX6

Technical Support
, , , ,
21

This is also not working

{
    "config_format": 1,
    "autoinstall": true,
    "name": "Toradex Easy Installer for u-boot reprogramming",
    "description": "u-boot reprogramming for Colibri iMX6.",
    "version": "1.3",
    "release_date": "20171201",
    "wrapup_script": "wrapup.sh",
    "icon": "tezi.png",
    "supported_product_ids": [
        "0014",
        "0015",
        "0016",
        "0017"
    ],
    "blockdevs": [
        {
            "name": "mmcblk0boot0",
            "content": {
                "rawfiles": [
                    {
                        "filename": "SPL",
                        "dd_options": "seek=2"
                    },
                    {
                        "filename": "u-boot.img",
                        "dd_options": "seek=138"
                    }
                ],
                "filesystem_type": "raw"
            }
        }
    ]
}
22

Final comment.
The procedure done from an existing u-boot is working.
You need to have the new bootloader installed on a USB stick. Do not use any SDcard.

  • do “run setupdate”
  • do “run update_uboot”.

Thank you

P.S. Explaining how to do that with Easy Installer would be very useful in production, so I ì’ll return asking that in the future though.

23

I don’t see why updating from an SD card should not working equally well as from an USB memory stick. In general all our U-Boot update scripts are completely media agnostic and should work with any block device be it an SD card or a USB memory stick.

Concerning updating from the Toradex Easy Installer rather than messing with any JSON files you would first need to have it running on the target in the first place. Why you do get some MD5 hash integrity error I do not know resp. I have not heard of anybody else having had any such issue as of yet. Are you absolutely sure your Toradex Easy Installer package was not corrupted in some way? Once you have it running you could just manually install your custom U-Boot only updating package before having it being auto installed using the autoinstall property. Or what exactly is it that you are trying to prove?

24

marcel.tx,

There must be something not so obvious and perhaps you are considering something as a pre-assumption driven by your experience. That’s normal for a developer, sometime I do the same but I also use to do a small effort to figure out what is the procedure followed by others.

However retrying the procedure done from an existing u-boot is not working.
do “run setupdate”
do “run update_uboot”.

The bootloader get corrupted somehow and I need to repeat all the recovery procedure every time and that’s definitely annoying.

mmc_load_image_raw_sector: mmc block read error
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

The problem is that your documentation is very fragmented and there is not a really clear step by step guide.

Just my two cents :wink:

25

The first thing is that u-boot configuration is a quite unclear because I suspect you are mixing instructions for BSP-2.7 and BSP-2.8

I am using Toradex BSP-2.8

This is my procedure to generate u-boot:

git clone -b 2016.11-toradex git://git.toradex.com/u-boot-toradex.git
cd u-boot-toradex

and then the configuration setup

 make colibri_imx6_defconfig

This generates

SPL + u-boot.img

Or I can use

 make colibri_imx6_nospl_defconfig

And this generates only

u-boot.imx

The problem now id what to do with these artefacts.
If I follow the Easy Installer procedure, I need to create a USB disk containing the TEZI dor BSP-2.8 called
Colibri-iMX6_LXDE-Image_2.8.1 there are these files:

colibri-imx6_bin/
├── flash_blk.img
├── flash_blk.scr
├── flash_eth.img
├── flash_eth.scr
├── fwd_blk.img
├── fwd_blk.scr
├── fwd_eth.img
├── fwd_eth.scr
├── fwd_mmc.img
├── fwd_mmc.scr
├── imx6dl-colibri-aster.dtb -> uImage--4.9-1.0.x+git0+1db9f06709-r0-imx6dl-colibri-aster-20171229003316.dtb
├── imx6dl-colibri-cam-eval-v3.dtb -> uImage--4.9-1.0.x+git0+1db9f06709-r0-imx6dl-colibri-cam-eval-v3-20171229003316.dtb
├── imx6dl-colibri-eval-v3.dtb -> uImage--4.9-1.0.x+git0+1db9f06709-r0-imx6dl-colibri-eval-v3-20171229003316.dtb
├── mk-u-boot-scripts.sh
├── SPL -> SPL-colibri-imx6-2016.11+gitAUTOINC+30a1208727-r0-spl-2016.11+gitAUTOINC+30a1208727-r0
├── SPL-colibri-imx6-2016.11+gitAUTOINC+30a1208727-r0-spl-2016.11+gitAUTOINC+30a1208727-r0
├── SPL-colibri-imx6-spl -> SPL-colibri-imx6-2016.11+gitAUTOINC+30a1208727-r0-spl-2016.11+gitAUTOINC+30a1208727-r0
├── SPL-spl -> SPL-colibri-imx6-2016.11+gitAUTOINC+30a1208727-r0-spl-2016.11+gitAUTOINC+30a1208727-r0
├── u-boot-colibri-imx6.imx-recover -> u-boot-recover-2016.11+gitAUTOINC+30a1208727-r0.imx
├── u-boot-colibri-imx6.imx-spl -> u-boot-spl-2016.11+gitAUTOINC+30a1208727-r0.imx
├── u-boot.imx -> u-boot-spl-2016.11+gitAUTOINC+30a1208727-r0.imx
├── u-boot.imx-recover -> u-boot-recover-2016.11+gitAUTOINC+30a1208727-r0.imx
├── u-boot.imx-spl -> u-boot-spl-2016.11+gitAUTOINC+30a1208727-r0.imx
├── u-boot-recover-2016.11+gitAUTOINC+30a1208727-r0.imx
├── u-boot-spl-2016.11+gitAUTOINC+30a1208727-r0.imx
├── uImage -> uImage--4.9-1.0.x+git0+1db9f06709-r0-colibri-imx6-20171229003316.bin
├── uImage--4.9-1.0.x+git0+1db9f06709-r0-colibri-imx6-20171229003316.bin
├── uImage--4.9-1.0.x+git0+1db9f06709-r0-imx6dl-colibri-aster-20171229003316.dtb
├── uImage--4.9-1.0.x+git0+1db9f06709-r0-imx6dl-colibri-cam-eval-v3-20171229003316.dtb
├── uImage--4.9-1.0.x+git0+1db9f06709-r0-imx6dl-colibri-eval-v3-20171229003316.dtb
├── uImage-imx6dl-colibri-aster.dtb -> uImage--4.9-1.0.x+git0+1db9f06709-r0-imx6dl-colibri-aster-20171229003316.dtb
├── uImage-imx6dl-colibri-cam-eval-v3.dtb -> uImage--4.9-1.0.x+git0+1db9f06709-r0-imx6dl-colibri-cam-eval-v3-20171229003316.dtb
└── uImage-imx6dl-colibri-eval-v3.dtb -> uImage--4.9-1.0.x+git0+1db9f06709-r0-imx6dl-colibri-eval-v3-20171229003316.dtb

And as you can see there are SPL and u-boot.imx but as you can see at the beginning of this message, I don’t have both SPL and u-boot.imx when I compile.

So what is the expected procedure now to replace my bootloader in the TEZI image?

P.S. Even the TEZI Colibri-iMX6_LXDE-Image_2.7 has both SPL and u-boot.imx, so I am facing to the same issue.

26

There must be something not so obvious

No, it is very obvious to us. You are simply trying to mix stuff from pre-SPL times with later stuff relying on SPL. Unfortunately this is not handled well but is also not really considered a valid use case. If a customer always first sticks to updating to one of our official full BSP releases before trying to update separate parts of it then this will never ever happen. Unfortunately trying to mix and match separate parts of different BSP versions may not always be easily possible. Not much we can do about it I guess.

and perhaps you are considering something as a pre-assumption driven by your experience. That’s normal for a developer, sometime I do the same but I also use to do a small effort to figure out what is the procedure followed by others.

Yes, thank you.

However retrying the procedure done from an existing u-boot is not working. do “run setupdate” do “run update_uboot”.

And what exact versions of things are we talking about?

The bootloader get corrupted somehow and I need to repeat all the recovery procedure every time and that’s definitely annoying.

mmc_load_image_raw_sector: mmc block read error
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

The problem is that your documentation is very fragmented and there is not a really clear step by step guide.

That I fully agree and I take full responsibility for allowing others to document stuff in inconsistent ways. Concerning step-by-step guides this is exactly what we are working on improving however usually such special use cases like you describe are not quite covered and probably never will.

Just my two cents :wink:

And we are really thankful for all such input.

27

I must admit, due to limitations of the U-Boot OE multi config support things are really confusing around imx/img.

In 2.7 series and up to 2.8b1 we use multi configuration builds which build U-Boot with and without SPL (see colibri-imx6.conf in the 2.7/morty branch). Due to limitations of the UBOOT_CONFIG method, only a single UBOOT_SUFFIX can be chosen, which will be used for all U-Boot binaries in the deploy folder. We left it as default, which is .imx. But this is only the ending used in the deploy folder. At build time, OE actually builds an u-boot.img file in the spl config, and a u-boot.imx in the recovery config.

So u-boot.imx (which points to the U-Boot which is meant to be used with SPL) is actually an u-boot.img… You can check that by using mkimage -l u-boot.img, it will show that image type is in fact an U-Boot image:

$ mkimage -l u-boot.imx-spl
...
Image Type:   ARM U-Boot Firmware (uncompressed)
...

Compared to u-boot.imx-recovery, which is a proper Freescale i.MX boot image:

$ mkimage -l u-boot.imx-recovery
Image Type:   Freescale IMX Boot Image
....

Since SPL now allows to emulate SDP, and the recovery utility imx_usb can load a SPL and U-Boot using the i.MX Serial Download Protocol emulation in U-Boot, we switched to using SPL/U-Boot for both, recovery and regular images.

Long story short: Use colibri_imx6_defconfig then overwrite SPL and copy u-boot.img in the Tezi image. Finally, change the file name in image.json from u-boot.imx to u-boot.img.

From 2.8b2 on, it will always be called u-boot.img. Sorry about that.

28

I used the exact same procedure with the Colibri (imx6DL) and the V2.7.

Starting with the ‘colibri-imx6_lxde-image-tezi_2.7-20180104.tar’, I’m able to flash my colibri V1.0A using the easy installer product (colibri-imx6_toradexeasyinstaller_1.4-20180403). So far so good.

Next I started to build a U-Boot form sources, follwing the steps outlined in “Build U-Boot and Linux Kernel from Source Code”. As describe above I copied the SPL and u-boot.img from my build directory into the Tezi image directory, and also adjusted the image.json (u-boot.img instead of u-boot.imx) file.

Next I placed the contents of the Tezi image directory on an USB stick. The Colibri module has the tezi application up and running (no network cable attached), and the USB stick is detected. Next I flash the images from the USB stick to my module, everthing seems to be working fine.

Next step is to restart the module (or power cycle), the u-boot is started but somehow fails to load the linux kernel as it seems to be looking for a zImage (There’s only a uImage present).

What is going wrong, I must have missed something?

Below is the output at the serial port:
link text

Kind Regards,

Alberto