Update: see below
This took a bit longer than expected, but we now have an SD card image of Android release R13.4-GA on-line:
The primary reason this took so long is that we had to build our EULA system, but we also encountered a bug that’s been pestering us since R13.4-Beta. The symptom is that the system hangs with penguins on the screen after this message on the serial port:
Freeing init memory: 228K
This appears to be the same bug reported in the R13.4-Beta release, and we’ve narrowed it down a bit.
It turns out that the problem is that the system is going to sleep before booting. The system is going into a wait state and requires an interrupt before it will proceed. Unfortunately, there are a limited number of interrupts that can wake the processor. In particular, neither a normal USB request from say a mouse, nor the touch screen are currently configured as wake-up sources.
Some interrupts which are configured to wake the system include:
- USB Host (mouse/keyboard) plug/unplug
- USB OTG plug/unplug
- Android button press
We’ll be working to find the root cause of this over the coming days, but since there is a lot of good stuff in this image, we wanted to publish first. Once alive, the system seems very stable, though we do have limited experience at the moment.
Be sure to check out YouTube support in the browser. We pulled in a high-def movie trailer (Iron Man 3) and it looked really good, especially in full screen.
The image above was created using dd and needs an SD card of > ~2.5GB and a Linux machine to restore it. If your SD card shows up as /dev/mmcblk0, you can restore it like so:
~/$ sudo umount /dev/mmcblk0* ~/$ zcat imx-android-r13.4-ga-20121024.img.gz | sudo dd of=/dev/mmcblk0 ~/$ sync
The boot script is configured as the R13.4-Beta release such that you need to configure your bootargs variable in U-Boot according to the screen(s) you have attached:
|Screen and connection||bootargs|
|1080P HDMI||video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 video=mxcfb1:off|
|720P HDMI||video=mxcfb0:dev=hdmi,1280x720M@60,if=RGB24 video=mxcfb1:off|
|Freescale LVDS||video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666 video=mxcfb1:off|
|Boundary LVDS||video=mxcfb0:dev=ldb,1024x600M@60,if=RGB666 video=mxcfb1:off|
|Boundary RGB||video=mxcfb0:dev=lcd,CLAA-WVGA,if=RGB666 video=mxcfb1:off calibration tsdev=tsc2004|
This image is essentially the SD card image from the Freescale R13.4-GA images package, but with our R13.4-GA kernel and a a boot script, but there were some other tweaks that we’ll detail below.
The layout of the partitions is shown in the table below:
|1||BOOT||boot.img (kernel+RAM disk)||FAT – Bootscript, kernel, RAM disk|
|3||Extended||Houses Logical 5-9|
The primary difference here is that we supply a boot script, kernel, and RAM disk (uramdisk.img) in partition 1, formatted as FAT for ease of access. This will make it easier for you to access the pieces and also to hack the RAM disk, which is exactly what we did.
Freescale’s image tar-ball contains the kernel and RAM disk in a boot.img format, and we used William Enck’s perl script to split it into its’ constituent parts.
Also note that we changed partition 6 from ext4 to ext2 because U-Boot seems to hang while trying to find a recovery command script in that partition. As far as we can tell, the U-Boot 2009.08 branch doesn’t have support for ext4.
RAM disk updates
The R13.4 release from Freescale was built for use with their SABRE SD board, which has some functional differences from the SABRE Lite and Nitrogen6X. In particular, it contains an eMMC device, which is always present on /dev/mmcblk0 under Linux. Consequently, the init.freescale.rc script in the RAM disk had pointers to /dev/mmcblk1.
diff -Naurb origroot//init.freescale.rc rootfs//init.freescale.rc --- origroot//init.freescale.rc 2012-10-24 12:11:16.296986694 -0700 +++ rootfs//init.freescale.rc 2012-10-23 16:45:41.957443584 -0700 @@ -48,7 +48,7 @@ setprop ro.sf.hwrotation 0 # hdmi audio output - setprop ro.HDMI_AUDIO_OUTPUT 1 + setprop ro.HDMI_AUDIO_OUTPUT 0 # Set video overlay display mode setprop sys.VIDEO_OVERLAY_DISPLAY 1 @@ -128,8 +128,9 @@ on fs # mount ext4 partitions - mount ext4 /dev/block/mmcblk1p5 /system - mount ext4 /dev/block/mmcblk1p5 /system ro remount - mount ext4 /dev/block/mmcblk1p7 /data nosuid nodev nodiratime noatime noauto_da_alloc,errors=panic - mount ext4 /dev/block/mmcblk1p6 /cache nosuid nodev - mount ext4 /dev/block/mmcblk1p8 /device ro nosuid nodev + mount ext4 /dev/block/mmcblk0p5 /system + # mount ext4 /dev/block/mmcblk0p5 /system ro remount + mount ext4 /dev/block/mmcblk0p7 /data nosuid nodev nodiratime noatime noauto_da_alloc,errors=panic + mount ext4 /dev/block/mmcblk0p6 /cache nosuid nodev + mount ext4 /dev/block/mmcblk0p8 /device ro nosuid nodev + mount vfat /dev/block/mmcblk0p1 /boot nosuid nodev + + exec /sbin/ts_calibrator
Note that we also commented out the line which re-mounts the /system partition as read-only.
We presume that you’re going to hack this image, and that you’d want the ability to transfer your own
executables into /system.
We also changed the ro.HDMI_AUDIO_OUTPUT flag. This had no effect. Audio is still routed to HDMI if you’re using an HDMI monitor, but will route to the head-phone jack if you configure for either an LVDS or RGB display
The ts_calibrator line tests to see if a touch screen calibration file (/data/system/calibration) is present and the tsdev= clause is in the kernel command-line. If the answers are “no” and “yes” respectively, a minimal touch calibration is performed. The user is prompted to touch three points on the screen and to confirm by pressing a green box.
The next diff enables debugging through ADB as user root. Again, we presume that you want control over this image.
diff -Naurb origroot//default.prop rootfs//default.prop --- origroot//default.prop 2012-10-24 12:11:16.296986694 -0700 +++ rootfs//default.prop 2012-10-23 14:04:34.953929210 -0700 @@ -1,7 +1,7 @@ # # ADDITIONAL_DEFAULT_PROPERTIES # -ro.secure=1 -ro.allow.mock.location=0 -ro.debuggable=0 -persist.sys.usb.config=mtp +ro.secure=0 +ro.allow.mock.location=1 +ro.debuggable=1 +persist.sys.usb.config=mtp,adb
In the /system partition, we changed the mounts in etc/vold.fstab to match the SABRE Lite and Nitrogen6x. Note that because these directories use the device path as references, they only work with the top slot on the Nitrogen6X or micro-SD card slot on the SABRE Lite.
--- orig-system/etc/vold.fstab 2012-09-19 08:39:45.000000000 -0700 +++ system/etc/vold.fstab 2012-10-23 15:31:28.000000000 -0700 @@ -24,9 +24,9 @@ #used for usb otg host #dev_mount udisk /mnt/sdcard/udisk auto /devices/platform/fsl-ehci.0/usb #mount SDHC4 SD card /mnt/sdcard as primary storage forMX6Q SABER_LITE RevC -dev_mount extsd /mnt/extsd auto /devices/platform/sdhci-esdhc-imx.2/mmc_host/mmc1 +dev_mount extsd /mnt/extsd auto /devices/platform/sdhci-esdhc-imx.3/mmc_host/mmc0 #mount SDHC3 TF card to /mnt/extsd as external storage forMX6Q SABER_LITE RevC -dev_mount sdcard /mnt/sdcard 4 /devices/platform/sdhci-esdhc-imx.3/mmc_host/mmc0 +dev_mount sdcard /mnt/sdcard 4 /devices/platform/sdhci-esdhc-imx.2/mmc_host/mmc1 ## Example of a dual card setup # dev_mount left_sdcard /sdcard1 auto /devices/platform/goldfish_mmc.0 /devices/platform/msm_sdcc.2/mmc_host/mmc1
The final update we made was to add preliminary support for the ft5x06 touch panel and tsc2004 touch panels. This only required copying /system/usr/idc/eGalax_Touch_Screen.idc to ft5x06.idc and tsc2004.idc.
This isn’t sufficient to allow calibration on the TSC2004 resistive panel though. For that, we’ve copied a sample file into /data/system/calibration. In order to support on-line calibration, some additional (code) updates were necessary as shown this tree for Android R13.2. We copied the file /sbin/ts_calibrator from that release into the RAM disk.
Beyond the bug listed above, this release still has a couple of major omissions:
- Wi-Fi/Bluetooth support is missing. That is, we haven’t yet integrated support for the TiWi R2 module on Nitrogen6X.
- Camera support is currently non-functional.
We’ll be working on these once the bug above is fixed.
We haven’t quite found the root cause, but we found the trigger for this failure. It turns out to be this line in init.freescale.rc:
mount ext4 /dev/block/mmcblk0p8 /device ro nosuid nodev
As you can see in the table above, we didn’t place anything in this partition, so the mount fails. This doesn’t explain why the system stalls, but getting rid of the line or commenting it out allows the boot to proceed without a button press.
We’ll upload a new image shortly. Meanwhile, if you’ve already downloaded the image, you can replace your RAM-disk with this one or you can hack your own:
For those who want more details, we made some notes in this Linaro bug report.
This bug was made more difficult to track because the kernel turns off the serial port right before the Android init process runs. For the time being, we’ve added a patch to our boundary-imx-android-r13.4-ga kernel branch to leave the serial port on.
We also learned something new in the process. This line in init.rc controls the verbosity of the init process.
Changing that 3 to a 7 allows you to see all of the actions taken during init. Makes sense, huh?