Results 1 to 3 of 3
  1. #1

    Put a new kernel on a huawei u8650 without bricking it in the try


    I am new to the android world, and I am enjoying my experience with android. I thought this would be the best place to ask this, but if not, please, kindly direct me to the best place for this. I am a bit lost.

    This started a couple of days ago. I was toying with my phone, and I discovered that for some reason, whomever compiled my kernel decided that I don't need cifs support (but the fact is that I do).

    Coming from gentoo, setting up a cross compilation setup was not a big deal. I downloaded the kernel for my mobile, same exact version, and I managed to compile it using the MSM7x27 cpu type. I changed the default msm7x27 config only to add cifs, and then just let make run. It fails at the end, though I don't know if the error is relevant. See below...

      LD      vmlinux.o
      MODPOST vmlinux.o
    WARNING: vmlinux.o(.text+0xe474): Section mismatch in reference from the function msm_map_io.clone.0() to the (unknown reference)
    The function msm_map_io.clone.0() references
    the (unknown reference) __initdata (unknown).
    This is often because msm_map_io.clone.0 lacks a __initdata
    annotation or the annotation of (unknown) is wrong.
    To build the kernel despite the mismatches, build with:
    (NOTE: This is not recommended)
    make[1]: *** [vmlinux.o] Error 1
    make: *** [vmlinux.o] Error 2
    Well, giving make another run with CONFIG_NO_ERROR_ON_MISMATCH=y, the compilation finishes (and apparently without problems). I pick the cifs.ko module from its place, and copied it to the phone (which is of course rooted). I tried to insmod it, and it failed but not because of the vermagic info. The version and all is ok, and it tried to load the module without complaining about that, however it failed with a very strange "file not found error". I looked at the dmesg output, and it turned out that it's segfaulting because it can't find some symbols. Unfortunately I have no way to find the .config from my phone, they also ripped that option from the kernel, so no /proc/config.gz for me, which makes this hard to fix, so... I thought that installing the kernel I just compiled would probably be the best choice, and it will -no doubt- match my cifs.ko file

    But... I still don't get how the android fs is laid out, and it seems to differ quite a bit from one device to the next one. From what I get, /proc/mtd holds the info about the partitioning, and I can cat the files in there to get images from the many fs's the phone has. The labels are descriptive enough, and mtd0 is "boot", which is clear enough.

    But there's where it all ends. I've tried cat'ing this to a file, but I have no idea what's inside of it. I tried to identify it with the "file" command, and it only says "data", which means nothing. I also read somewhere that some phones use yaffs2 as their fs, but the yaffs2 tools can't unpack it either. It's not compressed either because I couldn't open it with 7z, which opens about anything, even many fs image types.

    I guess this has, at least, an initramdisk and a kernel inside of it. But can't figure out how to separate them. There's some info around, for example here:

    But every single page about this topic is outdate, links are all broken, and things have probably changed quite a bit since that was written.

    Maybe there's a way to pick the kernel from the live fs. I am using qtadb to reach comfortable my phone fs from my pc. But I don't know where this thing stores the kernel, and I've never dealt before with arm bootloaders either. Ideally, I'd just install grub(2) on this thing and choose my kernel at boot time, which is what I do in my pc when I update the kernel, so if there's breakage I can easily reboot using my old kernel.

    I have a broad experience with linux so if you point me in the right direction I can probably continue myself without much guidance. It's just that even the official android site is giving buggy info, and I don't know where to look at.

    Thanks for any help you can offer, and if not, thanks anyway for reading this boring post.

  2. #2
    Just for the record, unyaffs2 reports this:

    $ android/yaffs2utils/src/unyaffs2 mtd0.img tmp
    unyaffs2-0.2.8: image extracting tool for YAFFS2
    warning: non-root users
    suggest: executing this tool as root
    image size (5242880) is NOT a mutiple of 2048 + 64
    operation incomplete
    files contents may be broken
    I know there are some yaffs2 fs's in the phone, because I see them when using the mount command without parameters in the phone terminal via qtadb. I can see that mtdblock4 to mtdblock8 are mounted as yaffs2 filesystems.

  3. #3
    Well, I've got some findings, but still no solution.

    The format of the boot image is as follows (pasted from my own notes.txt, in case someone else in the future needs this):

    $ cat notes.txt
    with photorec I was able to find a gz file inside the img
    uncompressing it I get what seems an initrd tree
    let's see what else...
    gzip file starts with
    1f 8b 08 00
    that sequence appears in mtd0.img at
    and also
    looking at the next few bytes I can see that
    the second ocurrence (0x307000) is the right one
    after some testing and visual recognition I managed
    to find that the header takes 2kb, thus 2048 bytes,
    from 0x0 to 0x7ff.
    So, the frangments are as follows
    0 to 0x07ff, header, bootloader or whatever it is
    0x800 to 0x306fff, kernel, it's recognised by the
    file tool!
    0x307000 to 0x500000, the initrd image, gzipped
    and cpio'ed, uncompress with zcat foo|cpio -i
    useful info is only at the beginning, most of
    the file is meaningless
    repack with
    find . | cpio -o -H newc | gzip -n > ../newramdisk.cpio.gz
    I then just cat all the parts together to, and use fastboot to flash it, but I haven't managed to boot any of the images.

    To make sure that it's not something stupid I did with the kernel or the initrd, I have tried to just unpack and re-join all the parts of the boot.img. I have checked myself with a visual binary file diff tool that the files only differ from 0x00307000, which is where the initrd starts. That's no surprise, since when uncompressing it a lot of trailing garbage is discarded, so the new initrd file is like 75% smaller.

    I also tried filling the gap with the trailing info on the original boot.img, to make them match in size. But that didn't help either.

    I am thinking that this might just be some obscure issue with gzip. I tried gzip with and without -n (because in the hex editor I could see that the original rd did not had the file name stored so I tried to follow that path also). Again, no difference. Maybe the gzip version? Dunno. If I find something else, I'll let you know.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts