Hi Toradex,
We previously had the firmware for our product running fine on previous versions of the Apalis card (1.1A & 1.1B) which had images prior to 2.6 BSP. With 1.1C the default uboot did not have the saveenv command, which we require in our product.
Assuming that 1.1C comes with BSP 2.7 flashed by default, we BSP 2.7 successfully flashed (Single Board Computers (SBCs), Computer on Modules, System on Modules) and noticed that BSP 2.6 onwards, the Uboot is written into ‘mmc dev 0 1’ while all previous BDPs had Uboot written into ‘mmc dev 0 0’. On top of that, BSP 2.7 has a SPL in conjunction with the Uboot.
My question is, is there a way we can revert to the Uboot from BSP 2.4 or 2.5 while keeping everything else from BSP 2.7? I tried to manually write the the UBoot from BSP 2.4 over the SPL’s location of BSP 2.7 but that cause Uboot to hang:
U-Boot 2015.04 (May 18 2015 - 13:08:37)
CPU: Freescale i.MX6Q rev1.5 at 792 MHz
Reset cause: POR
I2C: ready
DRAM: 2 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
I feel it has something to do with partition where uboot is.
To reiterate, the BSP on its own works fine, but using the latest BSP is out of the question as we have to support our product that has both different versions of Apalis.
What you are seeing is really the U-Boot that comes pre-installed with the Toradex Easy Installer. That one avoids any preserved U-Boot environment which may adversely influence operation particularly during recovery and simply relies on its built-in default environment. Just install any regular recent U-Boot (e.g. stable V2.6 or latest beta 2.7b3) and you will have saveenv again. Unfortunately installing any older pre fast boot mode resp. hardware area boot partition U-Boot is not really easily possible and won’t be supported by us. More information about this thematic may be found in the PCN or the following article on our developer website.
Thanks for your reply Marcel.
Just install any regular recent U-Boot
Can we use SPL and U-Boot from BSP 2.7? Do we just follow the loading of SPL and U-Boot into eMMC as in the flash_blk.scr?
It is alright for us to have recent U-Boot with hardware area boot partition. What we really need is to control where the U-Boot environment variables are saved to, as we have some custom environment variables. In 2.4 BSP, we have the following:
root@apalis-imx6:~# cat /etc/fw_env.config
# MTD device name Device offset Env. size Flash sector size Number of sectors
/dev/mmcblk0 0x80000 0x2000
In BSP 2.7, we have:
root@apalis-imx6:~# cat /etc/fw_env.config
# Colibri iMX6/Apalis iMX6
# U-Boot environment is stored at the end of the first eMMC boot partition
# hence use a negative value. The environment is just in front of the config
# block which occupies the last sector (hence -0x200)
# Block device name Device offset Env. size
/dev/mmcblk0boot0 -0x2200 0x2000
Instead of using the end of the first eMMC boot partition to store the U-Boot environment, is there anyway to configure U-Boot to use back the same flash space in U-Boot in earlier BSPs ( /dev/mmcblk0 0x80000 0x2000 )?
Can we use SPL and U-Boot from BSP 2.7? Do we just follow the loading of SPL and U-Boot into eMMC as in the flash_blk.scr?
Sure, either that or just use the Toradex Easy Installer to install the same.
Instead of using the end of the first eMMC boot partition to store the U-Boot environment, is there anyway to configure U-Boot to use back the same flash space in U-Boot in earlier BSPs (/dev/mmcblk0 0x80000 0x2000)?
I guess one could simply revert that however I would strongly advice against doing so and rather adjust/modify your user space to use the new future prove location.
Hi Marcel,
Could you indicate where or how I can revert this?
Probably along those lines but again I strongly advice against doing so!
Hi Marcel,
In BSP 2.7, MBR.bin is in mmc 0, part 0, block 1. The SPL and U-Boot are in mmc 0,
part 1, block 2 and mmc 0, part 1, block 138 (0x8a) respectively. In BSP 2.4 and 2.5, the U-Boot is in mmc 0, part 0, block 2.
I tried placing a U-Boot in mmc 0, part 0, block 2 but somehow, the system kept using the SPL+U-Boot in mmc 0, part 1, block 2. How can I overcome this?
Reading the PCN or the fast boot mode article on our developer website which I linked to above you should have realised that this is dependant on the i.MX 6 SoC fusing as well as the eMMC configuration parts of which being one time only settings and therefore irrevocable.
Please note that the BSPs V2.4 and V2.5 where only ever released as beta versions for resp. sample hardware at that time and we long since stopped supporting any of that.
Hi Marcel,
I took a look at the fast boot mode article and found this:
Booting from boot partition enabled:
root@colibri-imx6:~# cat /sys/devices/soc0/soc.0/2100000.aips-bus/2198000.usdhc/mmc_host/mmc0/mmc0\:0001/boot_info
[ 76.145225] mmc0: BKOPS_EN bit is not set
boot_info:0x07;
ALT_BOOT_MODE:1 - Supports alternate boot method
DDR_BOOT_MODE:1 - Supports alternate dual data rate during boot
HS_BOOTMODE:1 - Supports high speed timing during boot
boot_size:4096KB
boot_partition:0x48;
BOOT_ACK:1 - Boot acknowledge sent during boot operation
BOOT_PARTITION-ENABLE: 1 - Boot partition 1 enabled
boot_bus:0x0a
BOOT_MODE:1 - Use single data rate + high speed timings in boot operation mode
RESET_BOOT_BUS_WIDTH:0 - Reset bus width to x1, single data rate and backwardcompatible timings after boot operation
BOOT_BUS_WIDTH:2 - x8 (sdr/ddr) bus width in boot operation mode
It was stated that setting boot_partition back to 0x00 actually allows switching back to our current way of booting, which should be from ‘mmc 0, part 0, block 2’. I have an apalis 1.1c and ixora 1.1A with Apalis-iMX6_LXDE-Image_2.7b3-20170630. However, ‘cat /sys/devices/soc0/soc.0/2100000.aips-bus/2198000.usdhc/mmc_host/mmc0/mmc0:0001/boot_info’ does not exist. This is what I could find:
ls /sys/devices/soc0/soc/2100000.aips-bus/2198000.usdhc/mmc_host/mmc0/mmc0\:0001/
block date enhanced_area_size fwrev name preferred_erase_size rel_sectors type
cid driver erase_size hwrev oemid prv serial uevent
csd enhanced_area_offset ffu_capable manfid power raw_rpmb_size_mult subsystem
There was not soc.0 folder but just a soc folder. I could not find a boot_info file as well:
find / -name boot*
/sys/firmware/devicetree/base/chosen/bootargs
/media/sda1/apalis_imx6/boot.vfat
/media/sda1/$RECYCLE.BIN/$RL2JAP5/boot.vfat
/dev/disk/by-label/boot
/boot
/proc/sys/kernel/random/boot_id
/proc/sys/net/ipv4/conf/all/bootp_relay
/proc/sys/net/ipv4/conf/can0/bootp_relay
/proc/sys/net/ipv4/conf/can1/bootp_relay
/proc/sys/net/ipv4/conf/default/bootp_relay
/proc/sys/net/ipv4/conf/eth0/bootp_relay
/proc/sys/net/ipv4/conf/lo/bootp_relay
/proc/sys/net/ipv4/conf/usb0/bootp_relay
I did find the path in the Apalis_iMX6_LinuxImageV2.6_20160826 image but was not able to change the boot_partition back to 0x00. Any suggestions?
I don’t think a boot_partition of 0x00 is valid in the fast boot mode case. Looking at the spec “0x7: Boot from user area” might work. However again my word of caution as this is in no way validated & verified and we simply won’t support any of this!
It was stated that setting boot_partition back to 0x00 actually allows switching back to our current way of booting, which should be from ‘mmc 0, part 0, block 2’.
As mentioned before that really referred to the situation before we switched to using the fast boot mode.
I have an apalis 1.1c and ixora 1.1A with Apalis-iMX6_LXDE-Image_2.7b3-20170630. However, ‘cat /sys/devices/soc0/soc.0/2100000.aips-bus/2198000.usdhc/mmc_host/mmc0/mmc0:0001/boot_info’ does not exist.
You missed the following: “Linux kernels used in later BSPs do no longer allow accessing the boot_info via sysfs and you may use the mmc binary from the mmc-utils-cos package instead. Syntax is compatible to the U-Boot mmc command as explained below.”. That said we also updated the article to make this more clear.
