Page 4 of 13 FirstFirst 123456789 ... LastLast
Results 61 to 80 of 253
Like Tree15Likes
  1.    #61  
    Quote Originally Posted by GuyFromNam View Post
    Not sure if this is my test Veer acting up, but no response from the touchscreen after installing the super veer 2.2.4.
    Quote Originally Posted by Herrie View Post
    You have to do the PmTpUpdater manually still due to the 2.1.2 version of the uImage and therefore the new PmTpUpdater is not part of the Doctor. Same applies for A6 and Modem update.

    I'm not sure who could update the uImage with the updated files?
    This is incorrect for the MODEM FIRMWARE (it is part of the base build).

    Quote Originally Posted by GuyFromNam View Post
    I don't have to do anything.
    Quote Originally Posted by Herrie View Post
    ??? You need to run the PmTpUpdater and "start hidd" otherwise the Touchscreen won't work
    The TouchPanel firmware and A6 are included as part of the uImage, and unless I can figure a way of modifying the uImage they have to be done after the build (hence the developer mode is now enabled, read first post)..

    The MODEM firmware, is part of the BUILD it will update you if you are not at the correct version, but it will not re-flash (force) if you already have the newer firmware...

    Now if you already have the newer MODEM firmware and TP firmware both will remain during the build and you will only have to update the A6 (as it appears the build does backdate the A6 firmware).


    FYI I also released the base build webOS 2.2.3 script, will work on the super script for that later this week, it takes a long time to compare (~22000) files, I will compare to the Pre3 AT&T 2.2.3 build.
  2. #62  
    Quote Originally Posted by Herrie View Post
    ??? You need to run the PmTpUpdater and "start hidd" otherwise the Touchscreen won't work
    Ik moet helemaal niks!
    Last edited by GuyFromNam; 05/06/2012 at 03:20 PM.
  3. #63  
    Quote Originally Posted by GuyFromNam View Post
    Ik moet helemaal niks!
    Wel wanneer je een werkend TP wilt
  4.    #64  
    Dutch to English Translation, been a long time reading Dutch...

    Quote Originally Posted by GuyFromNam View Post
    Ik moet helemaal niks!
    I have nothing!

    Quote Originally Posted by Herrie View Post
    Wel wanneer je een werkend TP wilt
    Now if you want a working TP

    Again if your device is already at the correct TouchPanel (TP) firmware the builds will not back date the TP firmware (at least on one AT&T device tested many times).

    But if you have never updated to webOS 2.2.4/2.2.3 then yes one needs to update the TP firmware.

    To clarify the MODEM firmware, the builds will update the MODEM firmware only if you are not already there, it will not re-flash the MODEM firmware.
    Last edited by John Steffes; 04/18/2012 at 11:45 AM.
  5. #65  
    Quote Originally Posted by John Steffes View Post
    Dutch to English Translation, been a long time reading Dutch...



    I have nothing!
    ...
    Close "I have to do nothing!".

    It looks like we might be getting somewhere with the updated uImage

    I was able to extract the ramdisk from it, using the guide here:

    HOWTO: Unpack, Edit, and Re-Pack Boot Images - Android Wiki

    I will now try to ungzip and cpio it on my VirtualBox to see if that's working

    Then update and re-package with new A6 and Tp and we should be getting somewhere... The trick however I suspect is how to merge it back with the kernel?

    [edit]

    I get the following error with Super script:

    mkdir -p downloads
    Please download the correct version of the webOS Doctor .jar file
    and then rename and move it to downloads/webosdoctorp103ueuna-wr-2.2.4.jar (i.e. the downloads directory that was just created under the current directory).
    [/edit]
  6. #66  
    OK cpio doesn't seem to do the trick. I was able to split the kernel and the ramdisk image. The ramdisk image seems to be ext2 image. I can open it on Windows using Explore2fs and see the contents, extract it etc

    It seems we could suffice by replacing the following files:

    /usr/lib/ipkg/info/a6-firmware.control
    /usr/lib/ipkg/info/a6-firmware.md5sums
    /usr/lib/ipkg/info/pma6updater.control
    /usr/lib/ipkg/info/pma6updater.md5sums
    /usr/lib/ipkg/info/pmtpupdater.control
    /usr/lib/ipkg/info/pmtpupdater.md5sums
    /usr/lib/ipkg/info/pmtpupdater.list

    /lib/firmware/a6_firmware.txt (for A6, firmware file)
    /lib/cy8ctma300e.fw (for TP, firmware file)
    /lib/cy8ctma300e.ver (for TP, firmware file)

    /usr/bin/PmTpUpdater (for TP, update tool)
    /usr/bin/PmA6Updater (for A6, update tool)

    Then it would be required to update the MD5 in /md5sums.gz

    We could get the new files from the 2.2.4 rootfs, including their md5 sum

    Anyone has any idea how to update the ext2 image?
  7.    #67  
    Quote Originally Posted by Herrie View Post
    OK cpio doesn't seem to do the trick. I was able to split the kernel and the ramdisk image. The ramdisk image seems to be ext2 image. I can open it on Windows using Explore2fs and see the contents, extract it etc

    It seems we could suffice by replacing the following files:

    /usr/lib/ipkg/info/a6-firmware.control
    /usr/lib/ipkg/info/a6-firmware.md5sums
    /usr/lib/ipkg/info/pma6updater.control
    /usr/lib/ipkg/info/pma6updater.md5sums
    /usr/lib/ipkg/info/pmtpupdater.control
    /usr/lib/ipkg/info/pmtpupdater.md5sums
    /usr/lib/ipkg/info/pmtpupdater.list

    /lib/firmware/a6_firmware.txt (for A6, firmware file)
    /lib/cy8ctma300e.fw (for TP, firmware file)
    /lib/cy8ctma300e.ver (for TP, firmware file)

    /usr/bin/PmTpUpdater (for TP, update tool)
    /usr/bin/PmA6Updater (for A6, update tool)

    Then it would be required to update the MD5 in /md5sums.gz

    We could get the new files from the 2.2.4 rootfs, including their md5 sum

    Anyone has any idea how to update the ext2 image?
    Once you figure it out, post a script that will do it, I will use it in my script with the files from the rootfs tar ... ?

    can you mount the file system? Also for your error make sure you have the latest meta doctor makefile (git pull)
    Last edited by John Steffes; 04/18/2012 at 12:51 PM.
  8. #68  
    Quote Originally Posted by John Steffes View Post
    Once you figure it out, post a script that will do it, I will use it in my script with the files from the rootfs tar ... ?

    can you mount the file system? Also for your error make sure you have the latest meta doctor makefile (git pull)
    I can do the mount I noticed in my Ubuntu VirtualBox

    mount -t ext2 nova.ext2 /mnt/image -o loop
  9. #69  
    OK I got an updated image, how can I easily test it?
  10.    #70  
    Quote Originally Posted by Herrie View Post
    OK I got an updated image, how can I easily test it?
    use novacom memboot to see if it will boot device?
  11. #71  
    Quote Originally Posted by John Steffes View Post
    use novacom memboot to see if it will boot device?
    It doesn't any idea how to troubleshoot?
  12.    #72  
    Quote Originally Posted by Herrie View Post
    It doesn't any idea how to troubleshoot?
    Not knowing what you did...

    Once split and extracted compare the old ext2 to the new ext2 (diff) or hex edit...

    As you only need to change the a6 txt file and tp firmware files...

    Assuming both are gziped again most should be the same?

    We can the use dd (diskdupe) to patch the existing uImage?

    Looking further at the uImage it was made from uBoot and the CRC does not match...
    Last edited by John Steffes; 04/18/2012 at 10:49 PM.
  13. #73  
    File sizes are quite different as it seems.

    I did the following:

    Split the uImage into kernel and ramdisk and had the gzipped ramdisk ext2 there. Ungzipped ramdisk, mounted it and replaced the 2.1.2 versions with the ones from rootfs of 2.2.4 backup.

    Updated the md5sums and gzipped it.

    Then umount

    Then gzipped the ramdisk ext2 again

    did a copy/b kernel.uImage+newramdisk.ext2.gz newboot.uImage

    That's a short description.

    I'm not sure what's the difference between the Pre2, Pre3 etc ramdisk images?

    The gzipped ramdisk image starts with HEX "1F 8B 08 08" in the uImage.
  14.    #74  
    Quote Originally Posted by Herrie View Post
    File sizes are quite different as it seems.

    I did the following:

    Split the uImage into kernel and ramdisk and had the gzipped ramdisk ext2 there. Ungzipped ramdisk, mounted it and replaced the 2.1.2 versions with the ones from rootfs of 2.2.4 backup.

    Updated the md5sums and gzipped it.

    Then umount

    Then gzipped the ramdisk ext2 again

    did a copy/b kernel.uImage+newramdisk.ext2.gz newboot.uImage

    That's a short description.

    I'm not sure what's the difference between the Pre2, Pre3 etc ramdisk images?

    The gzipped ramdisk image starts with HEX "1F 8B 08 08" in the uImage.
    Again, not sure which files you replaced...

    But only replace the files needed?

    So the files I looked at are from webOS 2.2.3/4
    A6: /lib/firmware/a6_firmware.txt
    TP: /lib/firmware/cy8ctma300e.fw and /lib/firmware/cy8ctma300e.ver

    All under the same path...

    So this is a uBoot Image... we need CRC checksums to match...

    Ok here is my thoughts looking at uImage-2.6.29-palm-shank it starts a 000000 and ends at 27d350.

    So I look at the nova-installer-image-broadway.uImage and I see the kernel start at 00004c and ends at 27d3bf then a cool bunch of letters "ramdisk" at 27d3c0 then a bunch of 00 that end at 27d3df, the next code is 1f 8b (gzip) starts at 27d3e0.

    So my thoughts split the file into three start with first file from 000000 to 00004b (uBoot header), second file from 00004c and end at 27d3df, and the third from 27d3e0 to eof (bfbfb7)

    I split the file into three files and ungziped the third and as I am a using a MAC it needs to use MACFUSE and fuse-ext2 (http://alperakcan.org/?open=projects&project=fuse-ext2) to mount the ext2 filesystem...

    I validate I can mount and can replace the three files I gziped the third file (name of the ramdisk is nova-installer-image-broadway-432958.rootfs.ext2)...

    Now the uBoot Image need mkimage to work again having issue as I am not 100% sure of the switches (same issue I had with the PrePlus Kernel)...

    Wish HP/Palm would open source how to make a bootable uImage for the devices...

    Seems that is the big issue with Open webOS if there is no documentation on how to build a doctor, how is anyone going to use it on anything...

    At least I can't find any public documentation besides linux info, need device specific info... maybe if one had NDA developer rights, but then they can not talks about what they know...
    Last edited by John Steffes; 04/18/2012 at 10:38 PM.
  15. #75  
    John, you are awesome. My Veer's running 2.2.4 now, and I just updated the touchscreen and A6 firmwares.

    Can't wait to get it up and running so I can try Touch to Share with my Pre 3.
    Palm IIIc -> Sony CLIÉ T650C -> Sony TJ-37 -> Palm TX -> Palm Centro -> Palm Pre Bell -> Palm Pre Plus Bell/Verizon Hybrid -> HP Veer -> HP Pre 3 NA -> BlackBerry Classic -> BlackBerry Priv

    It's a Late Goodbye, such a Late Goodbye.

    Need OEM Palm Pre parts? See here
  16.    #76  
    Quote Originally Posted by ToniCipriani View Post
    John, you are awesome. My Veer's running 2.2.4 now, and I just updated the touchscreen and A6 firmwares.

    Can't wait to get it up and running so I can try Touch to Share with my Pre 3.
    Wish I could do more with the uImage but I am out of my league... and using a mac to develop linux uImages is just not working for me...

    I am glad the scripts works as it does now... Did you use the Super version or just the Base version?

    Tap to Share, does work open a web page on one at once you tap the logos (I seem to have to swipe) it opens on the other device (Bluetooth seems to be paired, but it does not show in profile)...

    I have tested the Veer to a Touchpad and Pre3.
  17. #77  
    Quote Originally Posted by John Steffes View Post
    Again, not sure which files you replaced...

    But only replace the files needed?

    So the files I looked at are from webOS 2.2.3/4
    A6: /lib/firmware/a6_firmware.txt
    TP: /lib/firmware/cy8ctma300e.fw and /lib/firmware/cy8ctma300e.ver

    All under the same path...

    So this is a uBoot Image... we need CRC checksums to match...

    Ok here is my thoughts looking at uImage-2.6.29-palm-shank it starts a 000000 and ends at 27d350.

    So I look at the nova-installer-image-broadway.uImage and I see the kernel start at 00004c and ends at 27d3bf then a cool bunch of letters "ramdisk" at 27d3c0 then a bunch of 00 that end at 27d3df, the next code is 1f 8b (gzip) starts at 27d3e0.

    So my thoughts split the file into three start with first file from 000000 to 00004b (uBoot header), second file from 00004c and end at 27d3df, and the third from 27d3e0 to eof (bfbfb7)

    I split the file into three files and ungziped the third and as I am a using a MAC it needs to use MACFUSE and fuse-ext2 (Alper Akcan : ~/projects/fuse-ext2) to mount the ext2 filesystem...

    I validate I can mount and can replace the three files I gziped the third file (name of the ramdisk is nova-installer-image-broadway-432958.rootfs.ext2)...

    Now the uBoot Image need mkimage to work again having issue as I am not 100% sure of the switches (same issue I had with the PrePlus Kernel)...

    Wish HP/Palm would open source how to make a bootable uImage for the devices...

    Seems that is the big issue with Open webOS if there is no documentation on how to build a doctor, how is anyone going to use it on anything...

    At least I can't find any public documentation besides linux info, need device specific info... maybe if one had NDA developer rights, but then they can not talks about what they know...
    John, great work as always!

    Maybe this is useful?

    Bootie - WebOS Internals

    It looks like Bootie accepts images generated with mkimage from u-boot tools.

    There are apparently two kinds of images:

    simple images are just the uImage as produced by kernel build process.
    multi images that have both the kernel and a ramdisk. Both the kernel and the ramdisk must be processed with mkimage first (kernel is processed by the build). It is important to pass -C none to mkimage when generating the ramdisk file, otherwise Bootie refuses to recognize it. Then generate the multi image like this:

    mkimage -A arm -T multi -C none -n 'test-multi-image' -d arch/arm/boot/uImage:/tmp/uRamdisk /tmp/uMulti

    When Bootie detects such a multi image, it uses bootargs-ramdisk variable as kernel argument instead of just bootargs, so no need to do any extra actions when trying to feed such a multi-image into the Bootie.
    And found the following for Touchpad:

    https://github.com/tmzt/msmb/wiki

    Create a uImage with mkimage and boot it with bootie on your TouchPad

    You will need mkimage from the uboot utils package (see Uboot_and_Mkimage) Make sure that lk and lk.bin exist in build-touchpad-apq, then

    cd $HOME
    cd src/lk
    mkimage -A arm -T kernel -C none -A arm -a 0x40208000 -e 0x40208000 -d build-apq-touchpad/lk.bin lk.uImage
    Sorry I'm more of a Windows guy and my *nix knowledge is quite limited, so cannot help out too much here I guess

    [edit]
    And from Open Source 2.2.4 MkImage:

    --- u-boot-1.1.2.orig/tools/mkimage.c 2004-11-20 16:06:36.000000000 -0800
    +++ u-boot-1.1.2/tools/mkimage.c 2009-02-23 16:37:59.444339397 -0800
    @@ -467,7 +467,7 @@

    /* Build new header */
    hdr->ih_magic = htonl(IH_MAGIC);
    - hdr->ih_time = htonl(sbuf.st_mtime);
    + hdr->ih_time = 0;
    hdr->ih_size = htonl(sbuf.st_size - sizeof(image_header_t));
    hdr->ih_load = htonl(addr);
    hdr->ih_ep = htonl(ep);
    Last edited by Herrie; 04/18/2012 at 10:54 PM.
  18.    #78  
    Quote Originally Posted by Herrie View Post
    John, great work as always!

    Maybe this is useful?

    Bootie - WebOS Internals



    And found the following for Touchpad:

    https://github.com/tmzt/msmb/wiki



    Sorry I'm more of a Windows guy and my *nix knowledge is quite limited, so cannot help out too much here I guess

    [edit]
    And from Open Source 2.2.4 MkImage:
    Herrie,

    I looked at that, did some of this with the PrePlus webOS 2.2.4 build, but could never get the uImage to work 100%... Seemed I missed some configuration part in the System Map file...

    Now I would need just to pass the Updated Kernel and ramdisk and have in spit out a new uImage, way more work then I have at this time to look into this... and a lot out of my league... If there was documentation from HP/Palm and a SDK environment that I could use on my MAC... but they have that only for APPS development not for Doctor development...

    I will tinker around with it here and there and if I figure it out I will post some script or something... But at this point I think the method we have is about the best I can do...

    Plus even if I do end up doing it not that I can publish it? or could I? I assume the kernel if I compiled webOS 2.1.2 from scratch, but I would still be using their "ramdisk" even if modified not sure the legal copyright parts?

    Also would have to build a compiling environment with the script, doable, but very messy...
  19. #79  
    Quote Originally Posted by John Steffes View Post
    Herrie,

    I looked at that, did some of this with the PrePlus webOS 2.2.4 build, but could never get the uImage to work 100%... Seemed I missed some configuration part in the System Map file...

    Now I would need just to pass the Updated Kernel and ramdisk and have in spit out a new uImage, way more work then I have at this time to look into this... and a lot out of my league... If there was documentation from HP/Palm and a SDK environment that I could use on my MAC... but they have that only for APPS development not for Doctor development...

    I will tinker around with it here and there and if I figure it out I will post some script or something... But at this point I think the method we have is about the best I can do...

    Plus even if I do end up doing it not that I can publish it? or could I? I assume the kernel if I compiled webOS 2.1.2 from scratch, but I would still be using their "ramdisk" even if modified not sure the legal copyright parts?

    Also would have to build a compiling environment with the script, doable, but very messy...
    I think you can suffice with just combining the header, 2.1.2 kernel part and the new ramdisk?

    This should be OK in a script I guess and not that difficult.

    1. Split the uImage, we can use the Android script for this I guess

    2. Ungzip the ramdisk ext2 image

    3. Mount it

    4. Replace the files

    5. Unmount it

    6. Gzip the new ramdisk ext2

    7. mkimage to combine the 2.1.2 kernel and new ramdisk again into a new uImage

    I will have a go at it when I have some time tonight.
  20. #80  
    Last edited by Herrie; 04/19/2012 at 07:35 AM.
Page 4 of 13 FirstFirst 123456789 ... LastLast

Posting Permissions