mfgtool gets stuck while loading Android 5.0 onto imx6 board based on SabreSD.

[jamespieterick]

Hi Everyone,

I an working on loading android 5.0.0.1 Lollipop onto our custom board that is based upon the Sabresd reference design. One of the main differences between our design and the Sabre board is that we are using an Atmel maxTouch touchscreen controller connected through the host USB port instead of the max11801 touch sensor connected through i2c.

When I attempt to load android onto our board using mfgtool, the download process appears to progress normally until it starts looping writing the following message over and over:

max11801_ts 1-0048: FIFO_RD_AUX_MSB read fails

I looked through the Android source code and I believe that I found the place where this message originates: line 130 of file max11801_ts.c in directory .../kernel_imx/drivers/input/touchscreen. The above message appears to be printed when the max11801 touch screen fails to respond to an AUX_measurement command sent over the I2C bus. Since the max11801 is not present on our board it makes sense that there is no response. I have removed this file from my build but I am still seeing this problem. Obviously this message is coming from  either somewhere else or from a file that I still need to rebuild.

What else might I need to be rebuild so that the code is no longer attempting to communicate with the max11801?

I have rebuilt and replaced all of the .img and .imx files tha are placed into the  ...\Profiles\Linux\OS Firmware\files\android\sabresd folder in the folder where mfgtool is located.

I am using mfgtool2-android-mx6q-sabresd-emmc-1.2g.vbs to start mfgtool. and I am attempting to load into emmc.

I am attaching a file with the debug output as well as a copy of the mfgtool log.

Thanks,

Jim Pieterick

Original Attachment has been moved to: mfgtoolDebugOut.txt.zip

Original Attachment has been moved to: MfgTool.log.zip

[KursadOney]

James,

There are two kernels you need to replace. The mfgtool loads a stock kernel to the memory first. This stock kernel is used to write the real kernel to the flash device. It seems you only replaced the kernel that is to be written to the flash.

Moreover, the stock kernel needs to have the support for the protocol the MFGTOOL is using. No, you don't need yocto to build this. You just need a compiler. You can use the pre-built yocto toolchain for example.

The mfgtool's document folder has a "Manufacturing Tool V2 Linux or Android Firmware Development Guide V2.docx" file that explains the process.

[jamespieterick]

Hi Kursad,

The documents folder that is associated with the version of mfgtool that I have to download android 5.0 does not have "Manufacturing Tool V2 Linux or Android Firmware Development Guide V2.docx" in it. I did find a copy in a documents folder associated with the mfgtool that came with android 4.4.2.1. The problem is that when I look for information about building the mfgtool kernel, I find the following information:

--------------------------------

How to Generate U-Boot and Kernel Image for MFG

Please refer to the BSP User Guide, chapter Build Manufacturing Firmware.

--------------------------------

Is this the wrong version of the document? If so where do I get a copy of the correct version?

With that said I still do not understand why I need to rebuild the mfgtool. The parts of my board that the mfgtool should care about are identical to the sabresd reference design. What's different is the touchscreen and the display.. Mfgtool uses neither of these. I have no trouble loading Android 4.4.2 onto my board with the version of mfgtool that comes with 4.4.2. When I attempt to load Android 5.0, the 5.0 version of mfgtool is attempting to communicate with the max11801 touch screen controller, failing and getting stuck in a apparent infinite loop. My opinion is that this is a bug. The mfgtool does not need the touchscreen to perform a download. It should not be trying to communicate with it and it definitely should not be getting stuck in an infinite loop when it can't communicate with the touchscreen controller. Is there a way for me to open a problem report against this tool?

My next question is this: Would the version of mfgtool that came with Android 4.4.2 work to download the Android 5.0 files? I realize that instead of .bin files the 5.0 load has .imx files. Can I just change the associated ucl.xml file? It seems like that would be a lot easier that figuring out how to fix and then build the 5.0 mfgtool.

[KursadOney]

James,

The mfgtool does not try to communicate with the touch controller. It's the kernel that the mfgtool loads that does this. The mfgtool follows a two step process:

1. It first loads a minimal u-boot and kernel for your board. For SabreSD, our team has prepared a kernel for this purppose. For your board, you need to prepare one. This kernel can be mostly identical to your normal kernel, except it needs to include the FSL serial download protocol + initramfs.

2. This minimal kernel then downloads the Android images (which include the *real* kernel that will ultimately run on your board). The minimal kernel then uses commands like dd, cp, fdisk, etc. to write the images onto the flash device on your board.

As you can see the mfgtool does not and cannot have a universal minimal kernel that will work on every board. The minimal kernel for SabreSD likely is not optimized for non-touchscreen operation so that's why it fails to work on your board. That said, if the 4.4.2 minimal kernel is working for you, you should be able to replace it with the one that ships with 5.0.0. Or as you asked, you can do the opposite. You can use the 4.4.2 downloader to download the 5.0.0 images.

The first way (using 5.0.0 downloader) :

You can find these minimal kernel/device tree/u-boot files in the Profiles\Linux\OS Firmware\firmware directory. zImage is the kernel file. The device tree file depends on the board and the configuration you are using. For example, zImage--3.10.53-r0-imx6q-sabresd-20150105054653.dtb is the device tree for the quad/dual version of imx6, running on SabreSD. Please see the BootStrap section of the profile you are using in ucl2.xml file for the file names.

The second way (using the 4.4.2 downloader) :

In this case, I am pretty sure you really don't have to replace the u-boot.bin files to u-boot.imx files. All you need to replace is boot-*.img, system.img and recovery-*.img files. You can compare the "Updater" section of the profile you are using in ucl2.xml and see if any of the images are written differently, but I wouldn't expect so.

In the long run, you have a couple of options:

1. Keep using mfgtool, and create your own minimal kernel etc.

2. There is also an open source third party tool called imx_usb_loader if you are more comfortable with linux than Windows. This is not as comprehensive as the mfgtool, but the idea is the same. You load a binary (in their case, u-boot) to the memory using the download protocol. Then you use this binary to write the real images on to the flash.

Let me know if this helps.

[jamespieterick]

Hi All,

I tried option 2 and I could not get it to work. I get as far as the following:

UTP: received command '$ echo 1 > /sys/block/mmcblk3boot0/force_ro'

UTP: executing "echo 1 > /sys/block/mmcblk3boot0/force_ro"

sh: can't create /sys/block/mmcblk3boot0/force_ro: nonexistent directory

UTP: sending Non-success to kernel for command $ echo 1 > /sys/block/mmcblk3boot0/force_ro.

utp_poll: exit with status 256

I am not sure what the issue is with this; I tried adding some mkdir commands to create /sys/block/mmcblk3boot0 but the system would not let me create it. I am not sure what the issue is here. An ideas?

[KursadOney]

James,

You cannot create directories in the /sys folder. This is a special filesystem that holds information exported by the kernel. Here is one document that talks about it:

https://www.kernel.org/pub/linux/kernel/people/mochel/doc/papers/ols-2005/mochel.pdf

What is your boot device? If it's not mmcblk3, then you need to modify the ucl2.xml file to reflect the boot device you are using.

However, if you just replaced the boot/system/recover img files, and if you are normally able to use the 4.4.2 mfgtool, this should not have happened. Either you inadvertently replaced another file or something on your board has changed. Can you try this:

1. Start with a vanilla 4.4.2 mfgtool and load android 4.4.2 on your board. Make sure this works.

2. Still using the 4.4.2 mfgtool, replace the 3 img files in the Profiles\Linux\OS Firmware\files\android\<board name> folder with the 5.0.0 versions for your board. Also replace u-boot-<board>.imx with the u-boot for your board. Make sure to save the originals, and the new ones are named exactly the same as the old ones.

Let me know if this doesn't work and where it fails.

[jamespieterick]

Kursad,

I was able to do step 1 without a problem. Mfgtool is able to load Android Kitkat onto my board successfully.

I then removed everythingt from ucl2.xml that did not appear to be involved in loading android onto the board. I reran mfgtool to verify that I did not break the download. Andoid 4.4 downloaded and ran successfully.

I trimmed down the Android 5.0 version of the ucl2.xml file. I verified that I can use it to successfully download to the Sabre board. I am attaching both ucl2.xml files. I have been using a vbscript to call the mfgtool for 5.0 I am also attaching that file.

When I attempted step 2 I did the following:

- I replace files boot.mg, ramdisk.img, recovery.img and system.img with the files from my 5.0 build.

- I replaced uboot-6q.bin with u-boot-imx6q.imx.

- I modified ucl2.xml so that the reference to uboot-6q.bin is replaced with a reference to uboot-imx6.imx.

Mfgtool appears to run successfully with this setup but when I try to actually run Android on my board it does not even start printing on the debug port. I suspect that the problem is related to the fact that the ucl2.xml file for Lollipop used mccblk3 and my modified one uses mmcblk0. I tried replacing all of the references to mccblk0 with references to mmcblk3 as well as replacing references to mmc0 with mmc3 but that did not help. I am not sure at this point what I should try next. Do you have any suggestions?

Thanks,

Jim Pieterick

[KursadOney]

James,

mmcblk number is just how the kernel iterates the interfaces. If you have a single MMC/SD device, then only writing to only one will work. If you have multiple, you need to choose the correct one obviously. Do you have more than one?

If you have only a single interface and the mfgtool succeeded, the problem is with the u-boot image you are writing.

I'm guessing you did this, but please don't forget to set the boot mode back to emmc from serial download mode. If you have done this, can you attach the USB cable to the OTG port and see if the unit goes back into the serial download mode even if it's set to "boot from emmc?" If that's the case, that means the bootrom couldn't find a valid boot image or device. If not, it was able to locate u-boot on the correct device, but u-boot is faulty.

[jamespieterick]

Hi Kursad,

I am seeing the symptom that you describe where the mfgtool sees the unit as an HID-compliant device when the boot switches are set to eMMC boot mode.. So it looks like the bootrom couldn't find a valid image. My suspicion is that I am downloading the boot image to the wrong location. Do you have any suggestions as to how I correct this?

Thanks,

Jim Pieterick

[KursadOney]

Can you re-run the process using the 4.4.2 mfgtool + 5.0 images and send me these two files:

* The board's console log during the whole process.

* mfgtool.log file that's generated in the mfgtool's root directory.

I can look at these and see if I can spot anything.

[jamespieterick]

Hi Kursad,

I also noticed that I did not attach the ucl2.xml file that I am using with the 4.4.2 mfgtool. I thought that I had done that previously. I am attaching it now.

Jim Pieterick

[KursadOney]

James,

The logs look OK. Your board has only one mmc device, so all mmc writes are correct. There are some differences in the partition map of 4.4.2 and 5.0, but these shouldn't cause a boot failure as far as I can tell.

Let's try the following. I'm attaching a boot tester program. After you flash your 5.0 image with the 4.4.2 tool, set the boot mode to eMMC and connect the USB cable to your PC. As you said it won't boot and will go to the serial download mode. Do not launch the mfgtool. Instead, using the utility attached, from a DOS window, type:

    Boot_Tester.exe -t mx6x -df test.inc

This will connect to the board and will read the boot log. It should tell us which device it's trying to boot from and why the boot process failed. Please copy paste that output and attach it here.

Meanwhile I'll look into the logs you attached some more and see if I can see any issues.

[jamespieterick]

Hi Kursad,

When I ran the tool this is what was printed to the command prompt window:

Microsoft Windows [Version 6.1.7601]

Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\admin>cd C:\Users\admin\Desktop\chess\Mfgtools-Rel-13.01.00_ER_MX6Q_UPD

ATER_test3\Boot Tester

C:\Users\admin\Desktop\chess\Mfgtools-Rel-13.01.00_ER_MX6Q_UPDATER_test3\Boot Te

ster>Boot_Tester.exe -t mx6x -df test.inc

MX6DQ opened.

HAB_TYPE: DEVELOP

Image loading...

download Image to IRAM OK

Re-open MX6x device.

Running BOOT DEBUG., press "ESC" key to exit.

Jim Pieterick

[KursadOney]

It doesn't show the boot log. Can you put the board in serial download mode and see if you can see the boot log that way?

You should see something like this:

[jamespieterick]

Hi Kursad,

I set the boot switch to 00001100 and tried again and I got the same output as wehn I did it with the switches set to 11010110:

Jim Pieterick

[KursadOney]

Hi Jim,

I'm attaching a newer code drop that was tested with the 1.5 TO. The boot log offset might have changed in the boot rom memory map. I'm not sure. Can you try this new version? The cmd line arguments have changed slightly:

Boot_Tester.exe -t imx -df 6test.inc

Another thing to test is to use a different USB port on your PC (especially a NON-USB3.0 port since USB3.0 and imx drivers don't seem to work well yet).

[jamespieterick]

Hi Kursad,

That seems to have helped. I've pasted the latest output below. Let me know what you think.

Thanks,

Jim Pieterick

--------------------------------------------------------------------------------------------------------------------

Microsoft Windows [Version 6.1.7601]

Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\admin>cd C:\Users\admin\Desktop\chess\Mfgtools-Rel-13.01.00_ER_MX6Q_UPD

ATER_test3\boot Tester2\i.mx6SLSXSDLDQDPQP_rev106

C:\Users\admin\Desktop\chess\Mfgtools-Rel-13.01.00_ER_MX6Q_UPDATER_test3\boot Te

ster2\i.mx6SLSXSDLDQDPQP_rev106>Boot_Tester.exe -t imx -df 6test.inc

MX6DQ or DQplus opened

HAB_TYPE: DEVELOP

Image loading...

download Image to IRAM OK

Re-open imx device.

Running BOOT DEBUG., press "ESC" key to exit.

*********************************************

    Boot Debug (106.1) for MX6DQ or MX6DQplus

    Build: Nov 10 2015, 21:43:53

    Freescale Semiconductor, Inc.

*********************************************

WDOG Fuse Disabled

Boot_cfg_1    = 0x60

Boot_cfg_2    = 0x58

Boot_cfg_3    = 0x00

Boot_cfg_4    = 0x00

SBMR2         = 0x22000001

  BMOD        = 10  Boot from GPIO/Fuses

  BT_FUSE_SEL = 0

  DIR_BT_DIS  = 0

  SEC_CONFIG  = 01

Persistent Reg Value: 0x40000000

iROM Version  = 0x15

USB_ANALOG_DIGPROG = 0x00630005

    Device         = MX6 Dual/Quad

    Si Revision    = 1.5

Log Entry #0    (0x00010002)  BOOTMODE - Internal/Override

Log Entry #1    (0x000200f0)  Security Mode - Open

Log Entry #2    (0x00030000)  DIR_BT_DIS = 0

Log Entry #3    (0x00040000)  BT_FUSE_SEL = 0

Log Entry #4    (0x00050001)  Secondary Image Selected

Log Entry #5    (0x00060001)  USDHC Boot

Log Entry #6    (0x00070000)  Device INIT Call

Log Entry #7    (0x000700f0)  Device INIT Pass

Log Entry #8    (0x00080000)  Device READ Data Call     Address: 0x00000000

Log Entry #10   (0x000800f0)  Device READ Data Pass

Log Entry #11   (0x00061fff)  Recovery Mode NONE

Log Entry #12   (0x000c0000)  Serial Downloader Entry

Log Entry #13   (0x00090000)  HAB Authentication Status Code:

                (0x000a2233)  Invalid Address

Log Entry #15   (0x000d0000)  Serial Downloader Call

                (0x0091712c)  Address: 0x0091712c

Type 0 to Exit

Type 1 to Read Memory

Type 2 to Write Memory

Type 3 to Read Boot Page

Type 4 to Memory Dump

Type 5 to OCOTP Bank Display

Press ESC to Quit!

C:\Users\admin\Desktop\chess\Mfgtools-Rel-13.01.00_ER_MX6Q_UPDATER_test3\boot Te

ster2\i.mx6SLSXSDLDQDPQP_rev106>

--------------------------------------------------------------------------------------------------------------

[KursadOney]

Jim,

According to this log, the proper device is selected but there is no bootable image. This may mean either:

* u-boot image is not valid.

* while u-boot is written to emmc, somehow it gets overwritten or corrupted.

First let's test the first one since it's easier to rule out. Can you replace the u-boot-6q.imx file with a known good u-boot-6q.imx (from your 4.4.2 build) and see you get get it to work?

If not we have to review the details of the procedure and see if there is anything that could cause an overwrite. One thing I noticed is the 5.0 mfgtool does the partitioning before it writes u-boot. You can compare the ucl2.xml files and see the order of that. Maybe changing that order might be it.

[jamespieterick]

Hi Kursad,

I tried what you suggested. I replaced u-boot-imx6q.imx with u-boot-6q.bin. I commented out the line in ucl2.xml that refers to u-boot-imx6q.xml and replaced it with a similar line that refers to u-boot-6q.bin:

----------------------------------------------

<!-- <CMD state="Updater" type="push" body="send" file="files/android/u-boot-imx6q.imx">Sending U-Boot</CMD> -->

    <CMD state="Updater" type="push" body="send" file="files/android/u-boot-6q.bin">Sending U-Boot</CMD>

----------------------------------------------

After running mfgtool with these changes Uboot runs but it stops as soon as it tries to start the kernel:

----------------------------------------------

...

Hit any key to stop autoboot:  0

kernel  @ 14008000 (6736272)

ramdisk  @ 15000000 (726562)

kernel cmdline:

        use uboot command line:

        console=ttymxc0,115200 init=/init video=mxcfb0:dev=ldb,LDB-XGA,if=RGB24 ldb=sin0 video=mxcfb1:off video=mxcfb2=off gpumem=96M fbmem=10M fb0base=0x17b00000 vmalloc=400M androidboot.console=ttymxc0 androidboot.hardware=freescale

Starting kernel ...

-------------------------------------------

So u-boot-6q.bin comes up but doesn't start the kernel. Also, apparently u-boot-imx6q.imx has issues as it is installed by this version of mfgtool. What do you suggest now?

Jim Pieterick

[KursadOney · Accepted solution]

Jim,

I think the difference is where we write u-boot.* file. I see u-boot.bin in 4.4.2 mfgtool is written with:

dd if=$FILE of=/dev/mmcblk0 bs=512 seek=2 skip=2

while u-boot.imx in 5.0.0 mfgtool is written with:

dd if=$FILE of=/dev/mmcblk%mmc%boot0 bs=512 seek=2

So the way to make it work with 4.4.2 and using u-boot.imx is to remove that "skip=2" statement. This is because the old u-boot.bin file had the IVT and the DCD as well as 1K zero padding at the beginning. However, in the newer releases, the u-boot.bin file has none of those. Instead we have u-boot.imx which has the ITV and the DCD, but not the zero padded area.

In addition to this, I also recommend using the mksdcard-android.sh.tar file from the 5.0.0 release. There is a slight partition map difference. This might not matter since the new partition is part of the "misc" partition that is really not used for anything AFAIK, but Android is a very complicated system and it's better to be on the safer side.

[jamespieterick]

Hi Kursad,

I did what you suggested:

- I removed the skip-2 from the dd command line. it now is as follows:

<CMD state="Updater" type="push" body="$ dd if=$FILE of=/dev/mmcblk0 bs=512 seek=2">write U-Boot to sd card</CMD>

I also replaced mksdcard-android.sh.tar (dated 6/3/2013 12:23AM) with the version from 5.0 (dated 1/15/2015 2:55 AM).

The unit now boots up when I set the switches to eMMC boot and apply power!

Thanks!

I am attaching my ucl2.xml file for your reference.

Jim Pieterick