I have two Apalis iMX6Q 2GB IT V1.1B with two Ixora V1.0A Carrier board.
I have upgrade one card with open embedded core to Apalis_iMX6_LinuxImageV2.6.1Beta1.
But there appears to have decreased performance in playing video with gstreamer.
So I try to downgrade the card to Apalis_iMX6_LinuxImageV2.4Beta1_20150518 with open embedded core but there is a Kernel Panic during the Linux boot.
Here you can compare the console log during the boot.
I have two Apalis iMX6Q 2GB IT V1.1B with two Ixora V1.0A Carrier board.
I have upgrade one card with open embedded core to Apalis_iMX6_LinuxImageV2.6.1Beta1. But there appears to have decreased performance in playing video with gstreamer.
Did you report this decreased gstreamer video performance?
So I try to downgrade the card to Apalis_iMX6_LinuxImageV2.4Beta1_20150518
Please note that we no longer support any of those older beta BSP versions. Please either use the latest stable version being V2.6 at the time of this writing or the latest beta version which would be V2.6.1 beta 1.
with open embedded core but there is a Kernel Panic during the Linux boot.
Here you can compare the console log during the boot.
To me it looks like the two systems are not quite running equal stuff:
Different U-Boot versions
Default U-Boot environment vs. stored one
HDMI disconnected vs. HDMI connected
Different Linux kernels
Different kernel command line
Different vddpu voltage 1150 vs. 1450 mV
SD card unplugged vs. plugged
Ext3 recovery vs. devtmpfs mount error.
I therefore suggest you re-doing your test with exactly the same setup on both systems. Best would actually be to use our stock demo image so we can rule out any other side effects.
Does anyone know why this problem happens?
It looks like something during flashing of the rootfs may have gone wrong. Best would be to post log files of the whole update procedure as well.
This is the u-boot console log of updating process.
I have this message “** root.ext3 shorter than offset + len **”
Perhaps this is the problem
Apalis iMX6 # run update_it
reading mbr.bin
512 bytes read in 12 ms (41 KiB/s)
switch to partitions #0, OK
mmc0(part 0) is current device
MMC write: dev # 0, block # 0, count 1 ... 1 blocks written: OK
reading u-boot-it.imx
310272 bytes read in 31 ms (9.5 MiB/s)
switch to partitions #0, OK
mmc0(part 0) is current device
MMC write: dev # 0, block # 2, count 606 ... 606 blocks written: OK
reading boot.vfat
16777216 bytes read in 784 ms (20.4 MiB/s)
switch to partitions #0, OK
mmc0(part 0) is current device
MMC write: dev # 0, block # 8192, count 32768 ... 32768 blocks written: OK
reading root.ext3
268435456 bytes read in 12354 ms (20.7 MiB/s)
switch to partitions #0, OK
mmc0(part 0) is current device
MMC write: dev # 0, block # 40960, count 524288 ... 524288 blocks written: OK
reading root.ext3
** root.ext3 shorter than offset + len **
189792256 bytes read in 8783 ms (20.6 MiB/s)
switch to partitions #0, OK
mmc0(part 0) is current device
MMC write: dev # 0, block # 565248, count 370688 ... 370688 blocks written: OK
resetting ...
I don’t think that this is the reason.
In 2.4 we load the rootfs in chunks of 256M into RAM and from there to eMMC. The last chunk is shorter than the requested size leading to the ‘root.ext3 shorter than offset + len’ message. That is expected behaviour.
What happens if you flash the V2.4 image from here as Marcel suggested so you use identical Kernel versions?