topic Re: Linux Binary Demo Files 2011.03 Release (L2.6.35_MX53_ER_1103_IMAGE). How to get "rootfs" Flashed. in i.MX Processors

Linux Binary Demo Files 2011.03 Release (L2.6.35_MX53_ER_1103_IMAGE). How to get "rootfs" Flashed.

Claude_Sylvain — Sat, 23 Apr 2011 15:19:01 GMT

Hello,

- Have anyone tried to Flash the new L2.6.35_MX53_ER_1103_IMAGE on
an i.MX53 QSB.

- I am stuck on extracting files from "rootfs" file.
The problem is that this BSP do not have a single "rootfs.tar.bz2"
file, as in the L2.6.35_MX53_ER_1101_IMAGE, but 2 "rootfs" files.
The 2 files are:
rootfs.ext2.gz
rootfs.jffs2
The above 2 files are really smaller than the previous
"rootfs.tar.bz2", and seems to not be a "tar" archive.

Claude

Re: Linux Binary Demo Files 2011.03 Release (L2.6.35_MX53_ER_1103_IMAGE). How to get "rootfs" Flashed.

PeterNewton — Sat, 23 Apr 2011 16:00:24 GMT

Not exactly, but I found lucid_1108.tar.gz on the Freescale website

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=IMX5...

and tried that. Click on UBUNTU_RFS_DEMOIMG_1101. The video acceleration did not work at all so I went back to 10.04. If you want to try that "ER_1103" file, and have access to a Linux machine, you can gunzip rootfs.ext2.gz and then mount it with the loop device. From there you can copy the files or make your own tarball.

mkdir somedir

sudo mount -o loop rootfs.ext2 somedir

I am not using the microsd for a file system. It is too slow for me to stand. I wonder if this is normal... A USB harddrive is better and SATA is working better still.

Re: Linux Binary Demo Files 2011.03 Release (L2.6.35_MX53_ER_1103_IMAGE). How to get "rootfs" Flashed.

Claude_Sylvain — Sat, 23 Apr 2011 18:29:27 GMT

Peter Newton said:

>
> Not exactly, but I found lucid_1108.tar.gz on the Freescale website
>
>    http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=IMX5...
>
> and tried that. Click on UBUNTU_RFS_DEMOIMG_1101. The video acceleration
> did not work at all so I went back to 10.04.
>

I have not tried that one. Maybe I will try it later.

>
> If you want to try that "ER_1103" file, and have access to a Linux
> machine, you can gunzip rootfs.ext2.gz and then mount it with the
> loop device. From there you can copy the files or make your own tarball.
>
>   mkdir somedir
>
>   sudo mount -o loop rootfs.ext2 somedir
>

- Thank a lot. I can now have access to files in "rootfs.ext2".

- However, when I boot the i.MX53 QSB using the 11.03 BSP,
there is some errors, and a segmentation fault.
The display can not be opened.
Le login prompt display "freescale" instead of "lucid", and
the password "lucid" do not work anymore.
What is the password for that BSP... There is no documentation
included in the BSP image :-(

- Below, a part of what is displayed in the remote serial console:

                      +++
starting pid 2202, tty '': '/sbin/getty -L ttymxc0 115200 vt100'
_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/freescale:0
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6
(EE) XKB: Couldn't open rules file /usr/share/X11/xkb/rules/base
(EE) XKB: No components provided for device Virtual core keyboard

Backtrace (0 deep):

Fatal server error:
Segmentation fault caught

Can't deallocate console 2 Device or resource busy

arm-none-linux-gnueabi-gcc (4.4.4_09.06.2010) 4.4.4
root filesystem built on Wed, 23 Mar 2011 12:24:50 -0500
Freescale Semiconductor, Inc.

freescale login: matchbox-panel: failed to open displaymatchbox-desktop: unable
to open display !
matchbox: can't open display! check your DISPLAY variable.
ts_open: No such file or directory
                      +++

>
> I am not using the microsd for a file system. It is too slow for
> me to stand. I wonder if this is normal... A USB harddrive is better
> and SATA is working better still.
>

Interesting, I have not noticed this SD Card slowness.

- For the moment, I am more concerned with the processor that get
really hot after some minutes of operation.
Some users say that it is due to the R199 bug. I am not sure of
that. But, since I have not patched yet the R199 bug on my
board, I can not get fixed on that yet.

- Also, 2 annoying things I noticed:

    - There is a current leak between the VGA monitor and the
    i.MX53 QSB, that make the i.MX53 QSB partially powered
    from the RGB monitor when the i.MX53 QSB 5V plug is removed.

    - When connecting a powered USB HUB to the i.MX53 QSB,
    that USB HUB become a power source that make the
    i.MX53 QSB stay powered, even if the 5V power plug is
    removed from the board :-/

Thanks a lot, again.
Claude

Re: Linux Binary Demo Files 2011.03 Release (L2.6.35_MX53_ER_1103_IMAGE). How to get "rootfs" Flashed.

iafg — Mon, 02 May 2011 16:51:15 GMT

SD Cards do come in different "speeds" or "speed grades"... does this account for the slowness you saw?

> I am not using the microsd for a file system. It is too slow for
> me to stand. I wonder if this is normal... A USB harddrive is better
> and SATA is working better still.
>

Interesting, I have not noticed this SD Card slowness.

Re: Linux Binary Demo Files 2011.03 Release (L2.6.35_MX53_ER_1103_IMAGE). How to get "rootfs" Flashed.

iafg — Mon, 02 May 2011 17:01:13 GMT

There is an errata in the first silicon which prevents the graphics from VPU operating at 1080p at the original spec voltage.

The fix for this is to raise the supply voltage for this domain.

Freescale are intentionally running T2.0 silicon at maximum core voltage. (VCC = 1.35V).

"The main reason the board runs hot is because we are intentionally running our T2.0 silicon at maximum core voltage. (VCC = 1.35V). While we are switching to T2.1 silicon beginning with the next production run, the software patch that sets VCC = 1.35V will remain in the Linux build for the foreseeable future. That means that Quick Start boards with T2.1 silicon will continue to run hot.

The Linux team is aware that they need to take the patch out.

If people are really concerned about the board running hot, they can make a modification in the U-BOOT code that will make it run cooler, at the expense of exposing the T2.0 VPU bug a little more.

In U-Boot, they can type the following (similar to the instruction on making video output changes):

setenv bootcmd ‘i2c mw 0x48 0x2f 0x60; i2c mw 0x48 0x3c 0x62;run bootcmd_mmc’

saveenv

What this change does is make the very first two commands that U-BOOT issues at boot are commands to the PMIC (0x48) to write (mw) to the VCC voltage set register (0x2f) a new voltage value of 1.3V (0x60) and then to the PMIC Supply register (0x3c) a command to ramp (0x62) to the new voltage value. Then the boot sequence will continue with the normal rest of the sequence (run bootcmd_mmc).

Then the users can make their own judgment on whether the board is running hot because of the increased VCC supply rail.

While we are switching to T2.1 silicon

I've been told that the errata fix accouts for the increased temperature of the chip.

The QS boards that ship in May should have the new silicon on them.

- For the moment, I am more concerned with the processor that get
really hot after some minutes of operation.
Some users say that it is due to the R199 bug. I am not sure of
that. But, since I have not patched yet the R199 bug on my
board, I can not get fixed on that yet.

Re: Linux Binary Demo Files 2011.03 Release (L2.6.35_MX53_ER_1103_IMAGE). How to get "rootfs" Flashed.

iafg — Mon, 02 May 2011 17:04:20 GMT

This is the link to the errata:

i.mx53 VPU errata

http://cache.freescale.com/files/32bit/doc/errata/IMX53CE.pdf?fpsp=1&WT_TYPE=Errata&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation

Iain Galloway (Future) said:

There is an errata in the first silicon which prevents the graphics from VPU operating at 1080p at the original spec voltage.

The fix for this is to raise the supply voltage for this domain.
Freescale are intentionally running T2.0 silicon at maximum core voltage. (VCC = 1.35V).
"The main reason the board runs hot is because we are intentionally running our T2.0 silicon at maximum core voltage. (VCC = 1.35V). While we are switching to T2.1 silicon beginning with the next production run, the software patch that sets VCC = 1.35V will remain in the Linux build for the foreseeable future. That means that Quick Start boards with T2.1 silicon will continue to run hot.

The Linux team is aware that they need to take the patch out.

If people are really concerned about the board running hot, they can make a modification in the U-BOOT code that will make it run cooler, at the expense of exposing the T2.0 VPU bug a little more.

In U-Boot, they can type the following (similar to the instruction on making video output changes):

setenv bootcmd ‘i2c mw 0x48 0x2f 0x60; i2c mw 0x48 0x3c 0x62;run bootcmd_mmc’
saveenv

What this change does is make the very first two commands that U-BOOT issues at boot are commands to the PMIC (0x48) to write (mw) to the VCC voltage set register (0x2f) a new voltage value of 1.3V (0x60) and then to the PMIC Supply register (0x3c) a command to ramp (0x62) to the new voltage value. Then the boot sequence will continue with the normal rest of the sequence (run bootcmd_mmc).

Then the users can make their own judgment on whether the board is running hot because of the increased VCC supply rail.
While we are switching to T2.1 silicon
I've been told that the errata fix accouts for the increased temperature of the chip.

The QS boards that ship in May should have the new silicon on them.

- For the moment, I am more concerned with the processor that get
really hot after some minutes of operation.
Some users say that it is due to the R199 bug. I am not sure of
that. But, since I have not patched yet the R199 bug on my
board, I can not get fixed on that yet.