I haven't had enough to get a One now, but I'm pretty interested in the phone. Yesterday I saw a thread on Chinese forum, saying that LOGO.bin contains the image shown in fastboot mode, and thus everyone can choose his preferred image (like CM's) even if he uses ColorOS. So I tried to extract the bitmap from LOGO.bin and replace it with my own picture.
Now I've succeed PARTIALLY in identifying the BIN file format and extracting the images. There's no enough time to dig into replacing the pictures though, but I think it won't be hard.
Here is what I find, for those "aggressive" themers and ROM devs who want custom boot splash screen:
The BIN file starts with the following structure:
C:
struct SPLASHHEADERINDEX {
char magic_code[8]; // = { 'S', 'P', 'L', 'A', 'S', 'H', '!', '!' };
int img_width;
int img_height;
int reserved; // What's this? I haven't figured that out.
int img_offset[6];
char padding[468]; // The header is 512 bytes. Thanks [user=5757424]@chillstep1998[/user] !
};
Right after this structure, the raw data of boot splash image begins. Every pixel is described by 3 bytes in B-G-R order. The pixels begin at the upper left corner and then stored in the order of left to right & up to down. You can read (img_width * img_height * 3) bytes and write them into a BMP file. NOTE that BMP files require 4-pixel alignment for every horizontal row (Google that for details, otherwise you will get a "Broken image" info in image viewers) In order to avoid this problem, I wrote a simple program in VB.NET and used Bitmap.SetPixel and Bitmap.Save to solve it.
This is the VB code for this procedure. (I can't do GUI programs in C++...)
Code:
Dim bmp As New Bitmap(img_width, img_height)
Dim color As Color
For y = 0 To img_height - 1
For x = 0 To img_width - 1
b = fs.ReadByte 'fs is the FileStream of BIN file. Already sought to correct offset.
g = fs.ReadByte
r = fs.ReadByte
If b = -1 Then b = 0
If g = -1 Then g = 0
If r = -1 Then r = 0
color = color.FromArgb(r, g, b)
bmp.SetPixel(x, y, color)
Next
Next
There are some zeros after (img_width * img_height * 3) bytes. I don't know what's for...
Then let's look at the other images. Their offsets are in the img_offset array of SPLASHHEADERINDEX. They have headers like this:
C:
struct SPLASHHEADERNONINDEX {
char magic_code[8]; // "SPLASH!!" without \0
int img_width;
int img_height;
int reserved; //Still don't know
char padding[492];
};
Right after the structure is the raw data. Process that as mentioned above.
The image at img_offset[0] is the one shown in fastboot mode
[1] is AT current test (original Chinese: AT电流测试. What's AT?)
[2] is RF test
[3] is WLAN test
[4] is charging
[5] is low battery warning
Previews for new images are coming soon...
However: there is one bug: the images extracted are "mis-placed". You need to move 0x0 to 164xHEIGHT (163xHEIGHT maybe) area to the right side of the image to get the correct pic. The images extracted from ColorOS' LOGO.bin are listed as follows:
SPOILER:
[0]
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
[1]
[2]
[3]
[4]
[5]
Boot splash
Does anyone know the cause of this mis-place problem? Although that can be solved easily in the code, but it's not very reliable. Maybe it's related to the "reserved" member?
Since the format is rather simple, modding and repacking will be easy. When I get some free time I'll make a tool for this...
still dangerous. We don't know whether there's logo signiture check, even if we know how to make a logo.bin.
But good job!
dlhxr said:
still dangerous. We don't know whether there's logo signiture check, even if we know how to make a logo.bin.
But good job!
Click to expand...
Click to collapse
Can't come up with any reason why there should be signature check for logo, especially when we can use home-made modem fimwares and kernels without any problem... But it's worth considering since there's "reserved" member. ColorOS gets 0x00 0x00 0x00 0x00 and CM 0x00 0x00 0x00 0x01 in boot splash's "reserved" int. Haven't checked other 6 images though.
We already know how to make our own logo.bin...there's a thread in the "Themes and Apps" section.
treChoy said:
We already know how to make our own logo.bin...there's a thread in the "Themes and Apps" section.
Click to expand...
Click to collapse
Wow I didn't notice it before... This thread is revealing secrets of the magic and pushing it further
But he says the header is 512 bytes, which is different from what I've found. I will take a look. However, since there are pics as small as ~300*30, skipping 512bytes may cause visible loss of the content. Maybe that's for splash screen only.
updateing said:
Wow I didn't notice it before... This thread is revealing secrets of the magic.
But he says the header is 512 bytes, which is different from what I've found. I will take a look. However, since there are pics as small as ~300*30, skipping 512bytes may cause visible loss of the content. Maybe that's for splash screen only.
Click to expand...
Click to collapse
As far as they've discovered on the thread, they've only really uncovered the workings of the splash screen. We know that fastboot is also affected by the LOGO partition, but we don't know how that ties in with the bootloader. The ColorOS LOGO.bin displays, "已進人fastboot..." when in fastboot mode, and the International LOGO.bin displays "Fastboot Mode" with the Cyanogen mascot.
One thing is for certain though: this is DANGEROUS. There's a very good possibility of bricking because of the LOGO partition's relationship with the bootloader. I was talking to another developer here about his work with the LOGO partition, and he said he bricked his phone, but recovered it by holding the power button, and then manually writing the correct LOGO partition using the 'dd' command.
I've contacted OnePlus support about this, so we should hear word back around Easter.
treChoy said:
As far as they've discovered on the thread, they've only really uncovered the workings of the splash screen. We know that fastboot is also affected by the LOGO partition, but we don't know how that ties in with the bootloader. The ColorOS LOGO.bin displays, "已進人fastboot..." when in fastboot mode, and the International LOGO.bin displays "Fastboot Mode" with the Cyanogen mascot.
One thing is for certain though: this is DANGEROUS. There's a very good possibility of bricking because of the LOGO partition's relationship with the bootloader. I was talking to another developer here about his work with the LOGO partition, and he said he bricked his phone, but recovered it by holding the power button, and then manually writing the correct LOGO partition using the 'dd' command.
I've contacted OnePlus support about this, so we should hear word back around Easter.
Click to expand...
Click to collapse
Hope OnePlus support team is open to this kind of mod...
As for the developer you mentioned, could you please ask him if he entered Qualcomm DLOAD mode and used some .hex file to boot the phone into mass-storage mode? I know when this (QHSUSB DLOAD device) shows up, the bootloader has already failed and this is the last recovering method of the phone. Seen it on my Xperia TX...
And the method mentioned in this thread will also work on CM's LOGO.bin, except for the 164xH issue.
updateing said:
Hope OnePlus support team is open to this kind of mod...
As for the developer you mentioned, could you please ask him if he entered Qualcomm DLOAD mode and used some .hex file to boot the phone into mass-storage mode? I know when this (QHSUSB DLOAD device) shows up, the bootloader has already failed and this is the last recovering method of the phone. Seen it on my Xperia TX...
And the method mentioned in this thread will also work on CM's LOGO.bin, except for the 164xH issue.
Click to expand...
Click to collapse
The developer is @demkantor . And I was wrong about how he unbricked his device. He said that after messing around with the LOGO partition, he got the dreaded "QHUSB_BULK" error, but after a few seconds, his OPO rebooted on his own. He had to 'dd' the regular LOGO partition to get his bootloader up and running. Original thread here: http://forum.xda-developers.com/oneplus-one/help/qhsusbbulk-help-t2848238
treChoy said:
The developer is @demkantor . And I was wrong about how he unbricked his device. He said that after messing around with the LOGO partition, he got the dreaded "QHUSB_BULK" error, but after a few seconds, his OPO rebooted on his own. He had to 'dd' the regular LOGO partition to get his bootloader up and running. Original thread here: http://forum.xda-developers.com/oneplus-one/help/qhsusbbulk-help-t2848238
Click to expand...
Click to collapse
I have once seen somewhere that you can find specific .hex file (e.g. MPRG8960.hex for MSM8960) to download into the phone by QPST Service Programming. Then the phone will boot into mass storage mode, where computer will recognize the phone as a removable disk drive. Now the whole internal storage is "mounted" on the computer and you can use dd to restore then.
(Google'd and it says only QHSUSB_DLOAD need the hex file. QHSUSB_BULK should be mounting the internal storage to computer automatically and dd will be available. Not sure about that. Example: http://forum.xda-developers.com/showthread.php?t=2582142&page=1)
yeah the header is 512 bytes. Now the images are all correct :victory:
Flashing a bad LOGO.bin did send me to the QHSUB_DLOAD mode and I tired rebooting holding down all three buttons. It did seem to work but after a bit it seemed to just boot on its own. Then I just used an adb shell to run dd commands to flash the proper .bin and all has been well since then
Still have been to busy with our newborn to look into anything deeper but between this thread and the one by @chillstep1998 and treChoy and other it looks to be all good!
Glad all is coming together on this end, keep up the great work all
dear thread creater.. i tell u what is that zeros after anything.
actualy android reads anything in block size.. like this
4,4,4,4,4.....
or 8,8,8,8,8.....
or 16,16,16,16...
or....
or...
or...
or 512,512,512,512...
or......
so.. if block size is 512 then it would read 512 bytes first..
now think what if there is only 50 or 51 bytes.. if will be a error.. if it has code to handle errors.. it is slow.
this is called alignment.. we say header is aligned to 512 bytes.
to make alignment it would add padding of NULLs(chr(0) in vb)
same nulls for the end of file to make it aligned to some size.
thank you.
m9j_cfALt said:
dear thread creater.. i tell u what is that zeros after anything.
actualy android reads anything in block size.. like this
4,4,4,4,4.....
or 8,8,8,8,8.....
or 16,16,16,16...
or....
or...
or...
or 512,512,512,512...
or......
so.. if block size is 512 then it would read 512 bytes first..
now think what if there is only 50 or 51 bytes.. if will be a error.. if it has code to handle errors.. it is slow.
this is called alignment.. we say header is aligned to 512 bytes.
to make alignment it would add padding of NULLs(chr(0) in vb)
same nulls for the end of file to make it aligned to some size.
thank you.
Click to expand...
Click to collapse
Thanks! I know there are some alignment rules, but didn't expect them to be here. I've seen aligning the whole file to 4 bytes or so, but little do I know that a section header needs alignment as well. I guess that's because this LOGO.bin is used in such a low-level "environment" that we don't have enough time & space to handle the non-aligned data. Am I right?
updateing said:
Thanks! I know there are some alignment rules, but didn't expect them to be here. I've seen aligning the whole file to 4 bytes or so, but little do I know that a section header needs alignment as well. I guess that's because this LOGO.bin is used in such a low-level "environment" that we don't have enough time & space to handle the non-aligned data. Am I right?
Click to expand...
Click to collapse
Hi man!
Do you know how change the battery animation when the phone is charging(when is off)?
I've tried to change the imgs in /res/images/charger, but you know, it doesn't work eheheh...
Can you help me?
Reive said:
Hi man!
Do you know how change the battery animation when the phone is charging(when is off)?
I've tried to change the imgs in /res/images/charger, but you know, it doesn't work eheheh...
Can you help me?
Click to expand...
Click to collapse
I don't have a OPO to test, all these analysis are theoretical. So I may not be able to help. Sorry...
Related
Hey,
Versions supported for colormod :
MAGIC/HERO/DREAM - 1.7
Nexus - 1.7 For 1.7.0.1 amonra recovery, refer to this Link
Versions supported for noncolormod :
All recoveries, even koush's except you wont see the difference cuz he never calls on the png's
Thanks to amon_ra for his recovery and thanks to all those he thanked
Script is based on the dev kitchen by dsixda. I removed everything that was not needed for this task.
Requirements : Device drivers properly installed
Windows Operating System
Instructions :
1. Download the 7z file and extract.
2. You will get 3 folders and 2 batch files.
3. Run either batch.
INFO:
Noncolormod just allows you to change background image and progressbar
Colormod batch does what the noncolormod does + allows you to customize the colors inside the recovery
Guys 2 tips :
1. If image is layered please flatten it in photoshop or edit in paint.
2. Use this tool to configure a range of colors. Just grab the decimal values and feed in the script.
FYI: This will not work with Koush's recovery as he ignores the background png
PS : Donot ask for assitance from amonra if you are using the repackaged recovery image produced by this script. He WILL ignore u
PS : I AM NOT RESPONSIBLE IF YOU ARE NOT CAPABLE OF FOLLOWING INSTRUCTIONS. I EXPECT A DECENT LEVEL OF UNDERSTANDING/TECHNICAL ABILITIES FROM THOSE WHO ARE USING THIS SCRIPT.
----------------------------------------------------------------
Update
*Added menu with additional properties
*Can now flash/boot recovery from menu
*Added option for size check
*Allows customization of progressbars
*Keyboard-console fixed for G1 users
*Text-color customization
*Updatescript color customizable
*ProgressBar height adjustable
*A LOT MORE STABLE
*Thanks to amonra no more trackball issues should occur on Hero
----------------------------------------------------------------
Future Updates Expected:
Will bring this to the droid, cliq and desire
Will try to see what else i can make user-optional
Preview :
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Heres the background for those who asked:
sweet,cant wait to try!
Care bears or nothing at all.
B3astofthe3ast said:
Care bears or nothing at all.
Click to expand...
Click to collapse
Well you are certainly entitled to your opinion. I just feel that Android is all about customization and the recovery should be no different.
One that I made ... if I get more time I will upload more
*** EDIT ***
This one looks really good with the green text. If your looking to try one out use this one as your first test. The mod is stunning!
Thats pretty nice, did you have any problems getting this to work ?
Daneshm90 said:
Thats pretty nice, did you have any problems getting this to work ?
Click to expand...
Click to collapse
No works great and the pic I uploaded looks fantasic in the recovery.
This option should have been here long ago!
What about text color? Any plans for your mod?
*** EDIT ***
Here are more:
Yea i was going to look into that, i hope it would be a simple hex edit, if not, i can always compile a couple of them with different colors and make a batch where the user selects which color they'd like. I will also be adding options to change the image that appears when flashing a rom, the loading bars, etc,etc....
Daneshm90 said:
Yea i was going to look into that, i hope it would be a simple hex edit, if not, i can always compile a couple of them with different colors and make a batch where the user selects which color they'd like. I will also be adding options to change the image that appears when flashing a rom, the loading bars, etc,etc....
Click to expand...
Click to collapse
Would the size increase effect the phone in a negative way down the road?
Like limited space for the recovery? What size is the area parition this expands to?
Also, what about the font size? any way to increase this at all?
I love this mod BTW
great job, works really well and very easy to do
Very nice, Was getting tired of stock recovery look on my N1
www.youtube.com/user/exclusivegslick
1wayjonny said:
Would the size increase effect the phone in a negative way down the road?
Like limited space for the recovery? What size is the area parition this expands to?
Also, what about the font size? any way to increase this at all?
I love this mod BTW
Click to expand...
Click to collapse
You cannot go over the space acquired for ur recovery. Im not too sure but i think its 5mb. If you do cat /proc/mtd you will see your partition and sizes. Not sure what units its in but i remember if my png's are too big in size, then it fails to flash. This is no different than flashing a recovery when an update comes out. Obviously the more you flash the shorter your lifespan of your devices cause nand has a certain number of write cycles.
Daneshm90 said:
You cannot go over the space acquired for ur recovery. Im not too sure but i think its 5mb. If you do cat /proc/mtd you will see your partition and sizes. Not sure what units its in but i remember if my png's are too big in size, then it fails to flash. This is no different than flashing a recovery when an update comes out. Obviously the more you flash the shorter your lifespan of your devices cause nand has a certain number of write cycles.
Click to expand...
Click to collapse
Great information, 5MB cause I saw it shoot up about a meg in size and have flashed a 4.* MB file already but was asking out of curiosity.
The background is static through all the menus but wiping the data / factory & flashing.
I wiped the dalvik-cache and the image stayed but when i wiped data/factory the image went away, background went black.
Then the black background stayed until reboot of the recovery but upon reboot the picture was here
It does this for flashing a rom and wiping, pretty much anything with the status bar.
Its not a bug, if u look a a couple of posts above i mentioned it. When you flash/wipe something a different image is called. Next update will have modifications for that as well.
FYI: Due to partition size limitations. By adding the option of customizing the flash_rom/wipe background, you have to make sure your size doesnt go over limit.
Daneshm90 said:
Its not a bug, if u look a a couple of posts above i mentioned it. When you flash/wipe something a different image is called. Next update will have modifications for that as well.
FYI: Due to partition size limitations. By adding the option of customizing the flash_rom/wipe background, you have to make sure your size doesnt go over limit.
Click to expand...
Click to collapse
Ah I missed that post , good stuff. Cant wait for the update!
Cheers
** EDIT **
You should update your first post like the G1 post and include some screens. Just a thought...
Ok so the recovery partition is 5.2MB. Update will come out in a matter of hours. I will try to see if i can put a size restriction in the batch file that checks for this.
Re: Recovery Background Changer
Update available : Added menu's with more options
the file is corrupted; when i download from the OP link and try to extract, it gives me error saying the file is corrupt; i get this message from WinRAR:
! C:\Users\Desktop\RecoveryChanger.7z: CRC failed in other\bin\cygpng12.dll. The file is corrupt
! C:\Users\Desktop\RecoveryChanger.7z: CRC failed in other\bin\cygpopt-0.dll. The file is corrupt
! C:\Users\Desktop\RecoveryChanger.7z: CRC failed in other\bin\cygpq.dll. The file is corrupt
! C:\Users\Desktop\RecoveryChanger.7z: CRC failed in other\lib\gtk-2.0\2.10.0\printbackends\cygprintbackend-file.dll. The file is corrupt
! C:\Users\Desktop\RecoveryChanger.7z: CRC failed in other\lib\gtk-2.0\2.10.0\printbackends\cygprintbackend-lpr.dll. The file is corrupt
! C:\Users\Desktop\RecoveryChanger.7z: CRC failed in other\bin\cygreadline6.dll. The file is corrupt
! C:\Users\Desktop\RecoveryChanger.7z: CRC failed in other\bin\cygreadline7.dll. The file is corrupt
! C:\Users\Desktop\RecoveryChanger.7z: CRC failed in other\bin\cygsasl2-2.dll. The file is corrupt
! C:\Users\Desktop\RecoveryChanger.7z: CRC failed in other\lib\sasl2\cygsasldb-2.dll. The file is corrupt
! C:\Users\Desktop\RecoveryChanger.7z: CRC failed in other\bin\cygserf-0-0.dll. The file is corrupt
! C:\Users\Desktop\RecoveryChanger.7z: CRC failed in other\bin\cygsigsegv-2.dll. The file is corrupt
! C:\Users\Desktop\RecoveryChanger.7z: CRC failed in other\bin\cygSM-6.dll. The file is corrupt
! C:\Users\Desktop\RecoveryChanger.7z: Error - operation failed
Re: Recovery Background Changer
hmm let me reupload then. sorry about that.
So now that we have found the leaking crack in the bootloader and proved it's usefulness fat-tire and others are going to start work on a couple of key projects that I could use a little help on.
This will also keep conspiracy theorists at bay who call me "extremely low IQ male rooster with social development issues" (Also I have no pies)
Here is how i see the next steps:
Strip down uboot (or other bootloader) and teach it boot from it's own partition.
For example install 2nduboot in /boot, hijacking the signature check and then setting a 1MB offset to look for the real, unsigned boot.img. Repeat for recovery.
This is the real hold up and why there is nothing to "flash" as of yet. (still no pies)
Finish CWM. 100% done.
Completed. See recovery.img here: http://forum.xda-developers.com/showthread.php?t=1440645
Work on CM9 for both SDcard and internal booting
See Below
So instead of insulting me. I am looking for some people to help work on these things. We are going to be doing this is private respostories and a private irc channel due to the stupid reward that is out there.
If you are wanting to work with me. The reward (if we get done by the 22nd) goes to Doctors Without Borders. This is where we should all be donating. No negotiating.
So PM me or come to #nook-tablet @ freenode
Reserved
Bootstrap-loader (Goal #1)
Here is some more details on my thoughts on bootstrapping /boot and /recovery to boot unsigned images.
Today we are only bootstrapping with a 2nduboot on the sdcard. This would allow custom kernels and ramdisks on emmc for things like easier root, overclocking, CM9, CWM, etc
So my thoughts were to bundle together a bootstrap bootloader (uboot obviously will work, but another project that was used for CM on the touchpad called, moboot, may be a nice option to get menus and such) and the unsigned kernel+ramdisk into one binary blob. The unsigned boot.img will be at a well known offset. This will allow us to act as "stock" as possible and do things like. Replace just the kernel with an OC one. Replace just the ramdisk with ro.secure=0, etc.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
This would also allow us to completely replace recovery with CWM.
Current Status: Fattire working on a meny for SD booting. Still discussing best way to do internal booting although using bauwks bootstrap uboots will work for now for emmc but incorporating a possible menu is being looked into. Low Priority
CM9 (Goal #2) Inprogress
There is a lot here and I am going to go at it pretty methodically adding one feature at a time. So graphics first, then key/touchscreen, usb gadget, etc.
There is a number of kernel changes that need to be done:
Find the closest git repo/branch/revision from omap zoom to apply B&N changes as a patch.
This will allow us to a) have revision history b) allow merging up to 3.0 easier
This is pretty important and if anyone is handy with git and knows of an easy way. Let me know
Backport key changes (fattire probably has this already done)
Backport usb gadget
Backport a hwrenderer compatable sgx drives (maybe move to a 3.x kernel at this point instead)
Backport
Current Status:
Teasers:
Wow. Thanks nemith for all the info. I will work with you and 100% will give the donation to them (verbal and writen agreement). From when I was building CWM on the GNex I remeber having to change one of the values in the .mk file to allow for adb.
Hi nemith,
That is a nice plan which aligned with my plan for modding u-boot to boot off the internal partitions .
I pushed some changes into my git repository on github which looks like #1 on your list. git://github.com/bauwks/Nook-Tablet.git
So for example, to build a 2nd u-boot that will install to the internal flash partition "recovery" and try to load the next stage at offset 256K of the internal "recovery" partition one would do:
(cd to u-boot directory and switch to second-uboot branch first, then)
PATH=/usr/local/arm-2010q1/bin:$PATH
make nt2ndboot_irecovery
make
./tools/build_nt_2ndboot_img.py -f -o irecovery.img u-boot.bin
dd if=/dev/zero of=irecovery.img bs=1 seek=262143 count=1 # pads to 256K size
Then, you can cat your irecovery.img and your real recovery.img together and blast them onto the recovery partition.
There is also a nt2ndboot_iboot config that will do the same, but is used on the "boot" partition.
I have only done minimal testing with the recovery partition 2nd uboot. I'm about to write a full image onto my recovery partition and see what happens
Update:
I flashed my recovery partition with irecovery.img + a random twrp2 image I had and it boots solely from internal flash! No more SD card needed, no more USB connection needed, just holding down power+N
nemith said:
So now that we have found the leaking crack in the bootloader and proved it's usefulness fat-tire and others are going to start work on a couple of key projects that I could use a little help on.
This will also keep conspiracy theorists at bay who call me "extremely low IQ male rooster with social development issues" (Also I have no pies)
Here is how i see the next steps:
Strip down uboot (or other bootloader) and teach it boot from it's own partition.
For example install 2nduboot in /boot, hijacking the signature check and then setting a 1MB offset to look for the real, unsigned boot.img. Repeat for recovery.
This is the real hold up and why there is nothing to "flash" as of yet. (still no pies)
Finish CWM. 100% done.
Completed. See recovery.img here: http://forum.xda-developers.com/showthread.php?t=1440645
Work on CM9 for both SDcard and internal booting
Started on this one as well. I can boot but haven't got adb working and no graphics (expected at this point)
So instead of insulting me. I am looking for some people to help work on these things. We are going to be doing this is private respostories and a private irc channel due to the stupid reward that is out there.
If you are wanting to work with me. The reward (if we get done by the 22nd) goes to Doctors Without Borders. This is where we should all be donating. No negotiating.
So PM me or come to #nook-tablet @ freenode
Click to expand...
Click to collapse
A bit on UI, cleanup, and various boot scenarios
Bauwks.. cool, glad emmc is is a go.
Current Status: Fattire working on a menu for SD booting. Still discussing best way to do internal booting although using bauwks bootstrap uboots will work for now for emmc but incorporating a possible menu is being looked into
Click to expand...
Click to collapse
UB2 update from me: A fruitful night with lots of fun enhancements, some modest UI feedback, and a sprinkling of safety/sanity fixes and other tweaks. SD and emmc options should be more convenient/consistent now, with recovery selection effectively handled by UB2 not UB1 (though power+n will remain an option obviously). I'll let nemith elucidate.
Also, bauwks, nemith suggested, and I thought it wasn't a bad idea, to expand to 512K instead of 256K as a partition buffer just to be on the safe side. I think he said the partitions are 16MB in all, so a little extra padding for possible future bloat is probably not a bad thing to have-- especially if there's gonna be a 2nd-bootloader "standard" (ie, so that any UB2 or menu will work in the future...) now's the time to decide- what do you think? Is 512 reasonable? Adding a single new .rle pushes you over. (We actually can eliminate two .rles right now, as the "charging" and "plugin" ones are effectively useless. I got rid of them, then added two more for feedback so I'm back to even, though eventually I'll probably get rid of them too.) What are your thoughts?
Considering I don't have an NT and I'm working blind here with nemith testing... I think this could wind up pretty nifty.
bauwks said:
Update:
I flashed my recovery partition with irecovery.img + a random twrp2 image I had and it boots solely from internal flash! No more SD card needed, no more USB connection needed, just holding down power+N
Click to expand...
Click to collapse
Nice!!!!
I was loathing the idea of having to keep a bootable sdcard in the thing forever. From my understanding of this, this hardware is now "cured", and just needs a special blob appended to the front of the boot and recovery partitions, eh?
dhkr234 said:
Nice!!!!
I was loathing the idea of having to keep a bootable sdcard in the thing forever. From my understanding of this, this hardware is now "cured", and just needs a special blob appended to the front of the boot and recovery partitions, eh?
Click to expand...
Click to collapse
Yeah. Or more specifically, everything in those partitions will need to be shoved over by a set amount to make room for UB2.
fattire said:
Also, bauwks, nemith suggested, and I thought it wasn't a bad idea, to expand to 512K instead of 256K as a partition buffer just to be on the safe side. I think he said the partitions are 16MB in all, so a little extra padding for possible future bloat is probably not a bad thing to have-- especially if there's gonna be a 2nd-bootloader "standard" (ie, so that any UB2 or menu will work in the future...) now's the time to decide- what do you think? Is 512 reasonable? Adding a single new .rle pushes you over. (We actually can eliminate two .rles right now, as the "charging" and "plugin" ones are effectively useless. I got rid of them, then added two more for feedback so I'm back to even, though eventually I'll probably get rid of them too.) What are your thoughts?
Click to expand...
Click to collapse
Hi fattire,
I guess it depends on how you look at it. I was looking at it like: an "image" is a concatenation of a 2nduboot and an Android kernel/ramdisk. To install, one would just dd the "image" to a partition. Then the 2nduboot wouldn't have to have a fixed max size that is predefined, if it needs to be increased you would just modify the partition offset in the bootcmd to load the stuff after the new size. It would also make updating the 2nduboot easier because it's part of the "image".
But, I have not worked with Android before so I do not have expertise in how images are typically deployed. If you always want the real image to be at a fixed offset then increasing to 512K makes a lot of sense. You are free to use the solution that best fits your problem.
By the way, the offset of the real image doesn't have to be a power of 2, it only has to be a multiple of the MMC sector size (512 bytes).
I can't really offer much as I am no android developer. I can modify basics and work thinsg out through educated trial and error but most of what you guys have been on about has been way out of my league. If it makes any difference I have 2 NTs one of which is brand new in a sealed box just sat waiting for the correct time to bother getting it out to play.
I'm quite happy to do testing, tweak things and do what I can where required.
Not sure what happened about the reward thing but as has been said before I think giving it to a good cause is a very decent and honest thing to do.
Doing it and donating the 'winnings' to a good cause is a far better idea and I commend you for following that route. Those that do it solely for the money aren't doing it for the reasons that I think XDA exists and from what I've seen before often get their money out of blatantly using other members hard work to make themselves look good, there always seems to be a lot of sitting on the fence then diving in at the last second and releasing something as their own when most of it isn't.
Anyway, enough babbling from me! Keep up the good work and when you think I can be of any help I will be more than happy to chip in where required.
bauwks said:
Hi fattire,
I guess it depends on how you look at it. I was looking at it like: an "image" is a concatenation of a 2nduboot and an Android kernel/ramdisk. To install, one would just dd the "image" to a partition. Then the 2nduboot wouldn't have to have a fixed max size that is predefined, if it needs to be increased you would just modify the partition offset in the bootcmd to load the stuff after the new size. It would also make updating the 2nduboot easier because it's part of the "image".
But, I have not worked with Android before so I do not have expertise in how images are typically deployed. If you always want the real image to be at a fixed offset then increasing to 512K makes a lot of sense. You are free to use the solution that best fits your problem.
By the way, the offset of the real image doesn't have to be a power of 2, it only has to be a multiple of the MMC sector size (512 bytes).
Click to expand...
Click to collapse
Presumably, the partition table is write protected along with the xloader and bootloader partitions, right? Now I guess that would be by power-on-write-protect rather than permanent write protect (which would obviously lock even THEM out of it...). Stupid question, but has anyone checked if the eMMC reset pin is connected to a test point on the board or on some gpio we can manipulate? I'm just wondering if we can pull something like a gfree on this sucker, especially since the eMMC is practically identical to the one on VISION/GLACIER/ACE, just larger. Bounce that reset pin and reinitialize the eMMC with write protect disabled, replace xloader and uboot with proper uncrippled ones, and BE GOD.
Progress on CM9 from @AndroidNemith http://twitpic.com/86hx6m - Twitter
dhkr234 said:
Presumably, the partition table is write protected along with the xloader and bootloader partitions, right?
Click to expand...
Click to collapse
Nope.
dhkr234 said:
Now I guess that would be by power-on-write-protect rather than permanent write protect (which would obviously lock even THEM out of it...)
Click to expand...
Click to collapse
Nope.
dhkr234 said:
Stupid question, but has anyone checked if the eMMC reset pin is connected to a test point on the board or on some gpio we can manipulate? I'm just wondering if we can pull something like a gfree on this sucker, especially since the eMMC is practically identical to the one on VISION/GLACIER/ACE, just larger. Bounce that reset pin and reinitialize the eMMC with write protect disabled, replace xloader and uboot with proper uncrippled ones, and BE GOD.
Click to expand...
Click to collapse
This is not the g2. It's not a write-protected emmc and a power cycle of the emmc will do nothing. I appreciate the enthusiasm, but you're coming to this very late.
More rambling...
If I'm not mistaken, the way you're suggesting is UB2 would be a prepended portion of the boot and recovery images as part of a "package", and this is how we were already discussing doing it in the cm9 build system-- this also matches in effect how Nook Color CM7 distros work-- the bootloader is actually re-installed with every update.zip (to enforce compatibility as newer versions of Android require newer u-boot).
However, I was considering that some people want to swap various u-boots in and out of existing boot or recovery partitions without necessarily having to push aside the rest of the image to make room. So if they're thought of as a unit, it makes total sense to do it as you suggest- but if UB2 is something that can be replaced (or updated) independently, then maybe a standard "buffer" size would be more appropriate.
We've talked about a few ideas- if a simpler boot menu is used to replace UB2, or a redirection to "see other partition for bootloader"... then it could be 512K (or whatever) mostly wasted... which may not be a big deal either.
Anyway, just typin' out loud. Lots of options, and no "right" way to do it.
bauwks said:
Hi fattire,
I guess it depends on how you look at it. I was looking at it like: an "image" is a concatenation of a 2nduboot and an Android kernel/ramdisk. To install, one would just dd the "image" to a partition. Then the 2nduboot wouldn't have to have a fixed max size that is predefined, if it needs to be increased you would just modify the partition offset in the bootcmd to load the stuff after the new size. It would also make updating the 2nduboot easier because it's part of the "image".
But, I have not worked with Android before so I do not have expertise in how images are typically deployed. If you always want the real image to be at a fixed offset then increasing to 512K makes a lot of sense. You are free to use the solution that best fits your problem.
By the way, the offset of the real image doesn't have to be a power of 2, it only has to be a multiple of the MMC sector size (512 bytes).
Click to expand...
Click to collapse
aversion of single-point-of-failure
I'd like to recommend, to avert the Single Point of Failure, a manditory and automatic backup of the /ROM/ partition. Since you're developing the first custom kernel, there will be a lot of work based upon yours for this device.
This can be handled in the init scripts. after /ROM/, /system/ and /sdcard/ mount. If the /ROM/ folder is available and there is no backup, make one. This simple step can save alot of grief in the future in case of damage.
Untested code:
Code:
#! /bin/sh
ROMBACKUPDIR="/sdcard/backup/ROM/";
BACKUPFILE=$ROMBACKUPDIR"ROMPARTITION.img";
TESTFILE="/ROM/NAMEOFANYFILE";
ROMPARTITION="/dev/block/***";
busybox test ! -e $ROMBACKUPDIR && mkdir --parents $ROMBACKUPDIR;
#no backup detected, so make one.
busybox test -f /ROM/$TESTFILE && busybox test ! -f $BACKUPFILE && busybox dd if=$ROMPARTITION of=$BACKUPFILE;
where ***=the ROM partition on your kernel and NAMEOFANYFILE=the name of any file on the /ROM/ folder
Whomever is building the AOSP!!!
Be careful with the ICS 4.0.3. There are alot of issues with the way the AOSP market place is working with it. The 4.4.3 Market has a tendancy to crash continually. Might be worth building ICS 4.0.2, and using that to elimitate all the problems whe can.
I have a mac g5 on public ip space and a NT that I can plug in if any dev's want to use that.
other than that, I'm another tester for y'all.
Loglud said:
Adam,
I own the nooktabletdev.org wiki, I will add all of those into it, or allow you an admin account. Then we can just point to there.
Click to expand...
Click to collapse
I've begun said post here: http://forum.xda-developers.com/showthread.php?p=21371828
Congrats to everyone who cracked it finally
I can say with 90% surity that You can recover a junked ROM partition or for that matter a fully junked eMMC, for the simple fact that it gives other pheriperals a chance before booting into eMMC (cannt say 100 % by myself immidiately now, because have been busy with other stuff at work over the last week, so my memory FIFO wrt my experiments on NookTab is bit blurry now).
AdamOutler said:
I've begun said post here: http://forum.xda-developers.com/showthread.php?p=21371828
Click to expand...
Click to collapse
Ahhhh, documentation!!!!
But seriously, thanks very much for that.
And FYI: Probably the best place to keep documentation is right here: http://forum.xda-developers.com/wiki/BN_Nook_Tablet -- in the xda device wiki.
Hey guys this just made you famous on the interwebz...
http://www.engadget.com/2012/01/14/nook-tablet-bootloader-bypassed-android-4-0-takes-its-first-ste
Good jorb!
Say hi to "CyanoBoot" -- a 2nd bootloader/w menu aka "ub2" - (WIP)
“CyanoBoot”
(aka a "second bootloader")
Quick Guide
by fattire
(@fat__tire on Twitter)
Alpha 0: "I don't have a NT" Edition
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
(Thanks to indirect for the image.)
What is CyanoBoot?
CyanoBoot (working title) is a “second bootloader” in early development, which is based on the open-source “u-boot” project, as further customized by BN & Bauwks. It is similar to the bootloader provided by Bauwks but has additional enhancements to make booting unsigned partitions easier and to generally enhance the booting experience on the Nook Tablet (aka “acclaim”) device.
CyanoBoot is intended for use with the forthcoming CyanogenMod 9, but it can also be used to boot CM7 or Ubuntu Linux or even the stock firmware (provided of course you are not legally or contractually bound from doing so. I haven’t read or agreed to any BN user agreements, so can’t speak to this.)
CyanoBoot includes an on-screen menu system, the ability to boot into three basic modes (normal, recovery, and “altboot”), configuration options, fastboot, and more.
The same version of CyanoBoot should start from both SD card and emmc (although it must be packaged and installed differently for each.) It should work on both the 1gb and 512mb RAM models. NOTE: It has been reported that some devices may require a USB cable to be plugged in to boot from SD Card. If true, this issue is not understood and is not addressed, nor is it likely to be.
NOTICE: CYANOBOOT (WORKING TITLE) IS HIGHLY EXPERIMENTAL AND IS NOT INTENDED TO BE USED BY NON-DEVELOPERS AND/OR THOSE UNWILLING TO ACCEPT FULL RESPONSIBILITY FOR ANY UNTOWARD CONSEQUENCES OF USING (OR ATTEMPTING TO USE) THE SOFTWARE. ALL SUCH ACTIVITY MUST OCCUR *ENTIRELY AT YOUR OWN RISK* AND YOU ACCEPT ALL CONSEQUENCES FOR DOING SO. THE USE OR ATTEMPTED USE MAY HAVE UNINTENDED RESULTS, INCLUDING BUT NOT LIMITED TO LOSS OF DATA, DAMAGE TO HARDWARE, AND/OR EXPLOSIVE DIARRHEA. CYANOBOOT IS NOT ENDORSED, AFFILIATED, SPONSORED, NOR ASSOCIATED WITH THE "DAS U-BOOT" PROJECT, GOOGLE, BARNES AND NOBLE LLC, TEXAS INSTRUMENTS, DENX., NOR ANY OF THEIR PARTNERS, OWNERS, EMPLOYERS, AFFILIATES, CLIENTS, SUBCONTRACTORS, OFFICERS, DIRECTORS, ADMINSTRATORS, INFORMATION PROVIDERS, ETC. EXCEPT INSOFAR AS THEY HAVE PROVIDED AND LICENSED SOURCE CODE TO BE FURTHER MODIFIED AND DISTRIBUTED. SEE THE RELEVANT GNU PUBLIC LICENSE FOR LICENSING DETAILS AND OTHER DISCLAIMERS. THIS SOFTWARE IS OBVIOUSLY INTENDED FOR USE ONLY BY THOSE WHO ARE AUTHORIZED TO DO SO.
Whew!
LIST OF THINGS
Started with “UB1” (aka u-boot, “first boot”) source code
Includes changes to support new 512MB model
Includes Bauwks’ repairs to fix “locked bootloader” malware
Many duplicate UB1 functions removed
One-build-boots-all (emmc or SD card, custom OS or stock)
Boot device indicator (top-left corner)
Bootcount indicator (top-left corner)
On-screen feedback to let you know what it’s loading.
Console-based boot menu
Support for key-combo shortcuts for menu/recovery
Alternate “Altboot” multiboot support allows 2nd OS.
Emmc setting for default boot profile (normal/altboot)
Emmc setting for default boot device (emmc or sd)
Emmc setting for automatic bootcount clearing
Boot fallback for stock firmware (0 bytes + sec. header)
Boot fallback for bauwks’ uboot (256 bytes)
Numerous visual enhancements
Unused bulky images removed (smaller file)
FASTBOOT support (w/menu selection)
On-screen build timestamp so you know version
Perhaps much more, or maybe not
There are likely bugs all over the place, but this is how it's supposed to work:
Key Shortcuts
Hold down home (“n”) key for the menu.
Hold down home (“n”) + “power” to have UB1 start recovery. If UB2 is also installed, it should respect this key combo and continue to load recovery.
The default behavior if no keys are pressed is to boot “normally”-- if booting from emmc, the boot partition (p4) from emmc will be booted. If booting from SD the boot.img on SD file will be booted.
The Boot Menu
Use the Home (“n”) key to navigate through the menu options. You can select an option with the power key.
The option you choose will override any other configuration you have made.
NOTE: Just so you don’t ask-- the reason the home and power keys are used to navigate through the menu rather than the volume up and down keys is due to a required driver not being included with u-boot 1. While the home and power keys use a very simple “gpio” method to detect if they are pressed, the volume keys are more like keyboard keys and thus are more difficult to detect. (The Nook Color bootloader, in contrast, did have the appropriate driver, so volume key detection was possible.)
Boot Indicators
Since you can boot from either SD or EMMC, it may be difficult to ascertain which version you are starting from.
Never again. You can now see whether you have loaded CyanoBoot from EMMC or SD by lookin at the top left corner:
“E” -> CyanoBoot is starting from emmc
“S” -> CyanoBoot is starting from SDCard
The # that follows this indicator is the current “bootcount”. After 8 unsuccessful boots or so, stock behavior is to run recovery with a reflash instruction. See below for instructions on clearing the bootcount at every boot automatically.
Fastboot (used for development)
For those familiar with “fastboot”, you can select the fastboot option from the CyanoBoot menu to go into fastboot mode. You can then (hopefully) flash to the boot or recovery partitions via USB cable using a command such as:
$ fastboot flash boot boot.img
Installation (SD Card boot)
(If you are preparing your own SD card for booting, you should be aware that for OMAP devices such as the acclaim, the SDcard must be formatted using a very specific configuration, which is detailed elsewhere.)
For SD Card, CyanoBoot is packaged inside a “flashing_boot.img” file to be placed in the first vfat partition of the SD-card along with the signed “mlo” and “u-boot.bin” files from the 1.4.2 update.zip.
(I'm told the mlo file may be called called MLO_es2.3_BN in the BN update.zip and should be renamed to “mlo”.)
Next, the boot (“boot.img”), recovery (“recovery.img”) and/or alternate boot (“altboot.img”) image files may optionally be placed in this partition.
Installation (EMMC boot)
To boot from emmc, the “flashing_boot_emmc.img” file, which contains a packaged version of CyanoBoot, should be put at byte 0 of the third partition (recovery) and ALSO at byte 0 of the fourth partition (boot). Then, the boot/recovery partitions must be shifted “to the right” (to make room for Cyanoboot) so that it starts 512Kb in from the start of the file. Use a padding of zeros so that the boot image contents begin exactly at 512Kb.
The boot and recovery partitions are expected to use this offset. For the alternate boot from emmc, the “altboot.img” may be the identical file used in an SD-boot, placed into the /bootdata vfat partition without any offset.
NOTE: Again, use the flashing_boot_emmc.img file for emmc boot partitions, *not* flashing_boot.img, which is for SD card boot.
Offset Info
Again, when used on the emmc, CyanoBoot must be placed at byte 0, at both the boot and recovery partitions. The “actual” boot.img and recovery.img that would normally be at byte 0 of those partitions should be moved so that it starts 512Kb in.
Always use this offset in recovery (p3) and boot (p4) partitions. In other words, put CyanoBoot at offset 0 and then pad with zeros, then put the normal boot.img or recovery.img at offset 512.)
On SD Card, the “boot.img” and “recovery.img” files should have no padding or offset or anything. Use as normal. This is similar to how “uImage” and “uRamdisk” files are used on the NookColor, only use a single file for both with a header in front.
Installation Summary
One more time. Here are the locations for the boot images:
SDCARD
(p1-vfat)/boot.img file (no offset/padding)
(p1-vfat)/recovery.img file (no offset/padding)
(p1-vfat)/altboot.img file (no offset/padding)
EMMC
(p4-/boot partition)<- CyanoBoot at byte 0, boot.img contents at 512.
(p3-/recovery partition)<- CyanoBoot at byte 0, recovery.img contents at 512.
(p6-vfat)/bootdata/altboot.img (no offset/padding, same as SDCard)
Configuration
You can control the "default boot" behavior (ie, what happens when you don’t hold down any keys). If you are a developer that does not want to constantly clear the bootcnt, you can also cause CyanoBoot to clear the bootcount automatically at every boot. To do this, three configuration files may be added to /bootdata (partition 6) on the emmc.
CONFIG #1: BOOT DEVICE
This will cause CyanoBoot to always boot from the emmc boot partition rather than SD. In this way, you can boot “through” a bootable SD card to whatever is on the emmc.
To Make Default Always Boot To EMMC
$ echo -n “1” > /bootdata/u-boot.device
CONFIG #2: ALTBOOT
Aside from the normal boot and recovery boot, a third boot option is available, called “altboot” (alternate boot). This is a kernel/ramdisk pair that can be used for a third firmware, an overclocked kernel, or whatever you like. If you choose the “altboot” as a default and it does not exist, your boot will fail.
As discussed above, the altboot.img file goes in the following location:
SDCard: file on p1 called “altboot.img” (no special padding or offset)
EMMC: file at /bootdata/altboot.img (no special padding or offset)
To Make Default Always Boot to “altboot”
echo -n “1” > /bootdata/u-boot.altboot
CONFIG #3: CLEAR BOOTCOUNT -- You can automatically zero out the bootcount with every boot. To set this:
To Make Default Automatically Clear BootCount
echo -n “1” > /bootdata/u-boot.clearbc
NOTE: A version of “Nook Tablet Tweaks” is planned to automate the above options much as Nook Color Tweaks does for the encore device in CM7.
Thanks/Credits
Thanks to chrmhoffman, nemith, xindirect, Celtic, and loglud for testing, as I don’t have a device and have never actually run this. Thanks to j4mm3r for the first encore menu code. It was pretty much rewritten for acclaim, but the first menu was invaluable in showing me how to add the code for the console. Thx to pokey9000 for stuff that helped get fastboot working.
Also thanks to BN as well as all the talented u-boot developers at Denx and elsewhere for the GPL’d code upon which this was based.
http://www.denx.de/wiki/U-Boot is where you can find the main u-boot project.
Also, a huge thanks to Bauwks for his code contribution as well as for making this possible in the first place!
Remember, this is all experimental. I'll try to update this post if there's something that needs to be updated.
(source)
If you have an issue, be sure to mention the timestamp at the bottom so everyone knows which version you're using. There will be bugs.
reserved for future expansion
Awesome
Hi,
Congratulations fattire. This is amazing work.
It boots the CM9 nicely.
Rgds,
Chris
I just gotta say, I laughed pretty hard when I read: Alpha 0: "I don't have a NT" Edition
Thanks
Wow
wow wow and we can use fastboot on the nook Tablet too? awesome
~ Veronica
Yep.
Works fine. Sometimes I have to re plug device though. But it speeds up things incredibly.
Chris
lavero.burgos said:
wow wow and we can use fastboot on the nook Tablet too? awesome
~ Veronica
Click to expand...
Click to collapse
Sent from my GT-I9000 using XDA App
Great work! Especially thanks for mentioning GPL software and folks behind it - that's thanks to them Android, Nook, Kindle, and even this bootloader were at all possible. So, where's source for the changes you made to this GPL software? Thanks again.
It's in the same directory. I'm going to make it a little clearer in the OP and I think maybe better organize the link to be in a subdirectory. So heads up that the links will change... ...changed.
fattire,
This looks great! Is it extensible to other devices like CWM recovery? I'd love to see this on the Transformer/Prime. Ubuntu on those devices replaces recovery, so it would be great to have a 2nd bootloader to get past these limitations. Also, it would be cool to see CyanoBoot on other devices like the NC and Touchpad. The TP has moboot but I think there's something to be said for consistency in this area.
Awesome work!
-mm
Yes, it'll work with CWM, TWRP2, or any other recovery. That's the point
Looks like the prime is a tegra3-based system. I don't know much about the bootloaders for Nvidia machines-- the nice thing about OMAP3/4 from Texas Instruments is that the u-boot bootloader works great, and is open source so you can extend it and stuff. While the bootloader for transformer is now unlockable I don't know that they give you the source, do they?
That said, from CM on the Qualcomm-based touchpad I know that a similar 2nd-level boot menu can be added AFTER the bootloader. Take a look at
the excellent moboot (lead developer is jcsullins) for an idea of how to add a very flexible menu that slips between the bootloader and the kernel. You can see it in action on youtube-- just look for any TouchPad cm7 or cm9 video where it boots up and you can select between CyanogenMod, WebOS, or one of the recovery images.
Hope that helps!
Mistar Muffin said:
fattire,
This looks great! Is it extensible to other devices like CWM recovery? I'd love to see this on the Transformer/Prime. Ubuntu on those devices replaces recovery, so it would be great to have a 2nd bootloader to get past these limitations. Also, it would be cool to see CyanoBoot on other devices like the NC and Touchpad. The TP has moboot but I think there's something to be said for consistency in this area.
Awesome work!
-mm
Click to expand...
Click to collapse
fattire said:
Yes, it'll work with CWM, TWRP2, or any other recovery. That's the point
Click to expand...
Click to collapse
Sorry, I was trying to ask if CyanoBoot would be available on multiple devices the same way CWM is. I understand it allows the booting of recovery images. What I did not realize was that uboot was tied to the TI OMAP platform, so you're answer was very helpful. Thank you!
Gonna be honest, I'm pretty sure this is for flashing roms such as how cwm allowed me to install cm7-teamb but I'm not sure. Also I saw someone say it flashes cm9? Sorry I'm just trying to get a feel at what this would really be used for, no offense intended.
fattire said:
It's in the same directory. I'm going to make it a little clearer in the OP and I think maybe better organize the link to be in a subdirectory. So heads up that the links will change... ...changed.
Click to expand...
Click to collapse
Thanks! Why not push it to github? (At least I had a look thru your repos on github yesterday and didn't see anything related, sorry if I missed something.)
Thanks for the awesome work fattire.
Here are the problems I found:
I manage to include cynoboot in recovery & boot but then there's device no found error using adb. Am I missing some drivers? (I am using WinXP)
because of that fastboot is not working too.
and then once enter fastboot mode. I can't get out unless I power off (n button can't navigate)
Hi,
you can use "fastboot reboot" to reboot the device. I didn't have an adb problem. Are you saying you try to adb into the device when in the menu? This doesn't work as there is no android running. I guess on windows you have to install android SDK first to get the drivers.
Rgds,
Chris
chrmhoffmann said:
Hi,
you can use "fastboot reboot" to reboot the device. I didn't have an adb problem. Are you saying you try to adb into the device when in the menu? This doesn't work as there is no android running. I guess on windows you have to install android SDK first to get the drivers.
Rgds,
Chris
Click to expand...
Click to collapse
I mean if I boot up the rom (I'm running MIUI) with the boot.img that includes cynoboot, then adb does not work (device not found). If I boot with the original boot.img, then no problem with adb
And fastboot command does not work for me either (I have android sdk installed)
I'll try the sdcard version later.
sungod88 said:
Gonna be honest, I'm pretty sure this is for flashing roms such as how cwm allowed me to install cm7-teamb but I'm not sure. Also I saw someone say it flashes cm9? Sorry I'm just trying to get a feel at what this would really be used for, no offense intended.
Click to expand...
Click to collapse
It's a bootloader
cobrato said:
I mean if I boot up the rom (I'm running MIUI) with the boot.img that includes cynoboot, then adb does not work (device not found). If I boot with the original boot.img, then no problem with adb
And fastboot command does not work for me either (I have android sdk installed)
I'll try the sdcard version later.
Click to expand...
Click to collapse
Are you using the 1.4.2 mlo and a 1.4.2 kernel?
fattire said:
Are you using the 1.4.2 mlo and a 1.4.2 kernel?
Click to expand...
Click to collapse
I'm using 1.40
Sent from my LT18i using Tapatalk
cobrato said:
I'm using 1.40
Sent from my LT18i using Tapatalk
Click to expand...
Click to collapse
cyanoboot is effectively a 1.4.2 u-boot.bin as far as handling the 512 model and all that goes. I don't konw that there were significant changes that would affect usb/adb, but jic you might want everything to match up...
Oh also, as far as fastboot goes... the device vendor_id was changed from 0x0451 to the google usb vendor id that most fastboots use which is 0x18d1. The device product_id is 0x0100.
Worked for chrmhoffman and others...
Hi,
New NSS beta is available for download. It will implement installing and restoring
of the bootloader as single click solution. Although the Qcom loader could be
installed via normal flashing, it is much easier this way. Also recovery is intended
to save manual hex editing or cmd line commands.
1. Download the new version
2. Extract to a folder, start the program
3. Insert the 2 loaders in \loaders\special\wp7\ - the qualcom file: RM803_12w07_prod_generic_nokia_osbl.esco,
posted by xorizont here , second file: RM803_11w48_prod_raw_nokia_osbl.bin attached (unzip first)
4. Go to Flashing->WP7 Tools
You are ready to play. Quick description:
- Read PMM button - reads the PMM partition with Nokia specific values(product
code, MAC addresses, et), you can edit in the boxes
- Write PMM button - writes back to the partition a selected value (via Update
checkbox)
Install button - use this to quickly install Qcom loader on 710(no way to load on
800 as the cert is checked)
Parse FS button - you can use this to test NSS partition parser and compare
against 3rd party tool, to make sure something catastrophically wrong will not
happen during recovery
Restore button - This will attempt to recover the Nokia production loader (so called DLOAD)
via raw NAND write into partition 2 of the connected phone. Make
sure you start in Normal mode as NSS will need to check phone type and battery
value (to make sure wrong file is not written to 800, or if the battery is critically
low)
Please keep in mind, this is a Beta version, it has been tested only on one phone
and is possible to be a major phone killer, so thread lightly. It is offered as it is,
with the hope of being useful, and I can't be held responsible for fatal results.
My best recommendation is to check the partitions after write/recovery with
3rd party tool and make sure all is ok before restarting the phone power. All this
until some recovery method is found (if somebody has found flashing routines in
SECBOOT or other loader, pls PM me).
BR, Chris
Thanks for this nice tool!
I just wanted to stress that:
- Read PMM button - reads the PMM partition with Nokia specific values(product
code, MAC addresses, et), you can edit in the boxes
- Write PMM button - writes back to the partition a selected value (via Update
checkbox)
Click to expand...
Click to collapse
Are only possible when the phone has the qualcomm loader right? Because only then it's possible to overwrite the values using the NAND access mode (Qualcomm MSD).
Hi,
Yes, only in NAND mode, on phones that have it. If you have Nokia DLOAD loader
and not hacked phone, you can only read those value via JSON call to NCSD appl.
There isn't any method coded to change them in Normal mode(at least i did not
find one yet).
BR
Bph&co said:
Hi,
Yes, only in NAND mode, on phones that have it. If you have Nokia DLOAD loader
and not hacked phone, you can only read those value via JSON call to NCSD appl.
There isn't any method coded to change them in Normal mode(at least i did not
find one yet).
BR
Click to expand...
Click to collapse
It's good to see there is now a userfriendly way of doing stuff like this. Thanks again
now all we need is a tool to write an .nb file with one click. can one do it?
mariosraptor said:
now all we need is a tool to write an .nb file with one click. can one do it?
Click to expand...
Click to collapse
To be honest i have no idea how that exactly works - is there a need for a file
system parser and proper replacing of a file, or just writting to a const location
in the last partition.
The mount never worked on my Ubuntu install(and i am complete Linux newbie).
Bph&co said:
To be honest i have no idea how that exactly works - is there a need for a file
system parser and proper replacing of a file, or just writting to a const location
in the last partition.
The mount never worked on my Ubuntu install(and i am complete Linux newbie).
Click to expand...
Click to collapse
Thanks God. there is someone else like me in linux.( humor, no offense ofcourse ;-) )
mate i have no idea how it works. nobody wants to write a very accurate tutorial.
not being able to flash the custom rom was the reason that i reverted my bootloader.
To unlock bootloader I used to NCS and firmware posted by xorizont. So how make connection under Windows7 before flash xorizont's firmware if Nokia is in DLOAD mode?
this is very helpfull for many people to get to qulcomm on 710!
+1
So You are able to load Qualcomm B. via NSS even if on the moment I have got DLOAD?
Hi,
New Beta - 0.47.1 - with ability to write moded OS files(.nb).
OS File button - select .nb file
Write OS button - loads the file onto the last partition (change to OSBL mode first)
As with the previous beta - make sure you check the partion parser for errors.
Write will be verified, but not the exact write address, so maybe good to have a
look with WinHex before restarting the phone.
BR
Already a new version, you're working hard man! ;-)
So if i understand correctly, you have automated the process of 'block writing' (which without this tool requires using dd) the created custom roms to the correct partition on the Lumia?
Of course this requires Qualcomm bootloader; for the 710 your tool can load this even if the phone currently has the newer Nokia DLOAD.
Hi,
Yes, i work even in my sleep Right now killing myself with the baseband diss, but
decided to have a break and make this.
It seems the OsBuilder creates raw partition image, to fit exactly into the OS part
of the NAND chip. So all i do is open the usb device as physical disk, parse the
partition structure and do a low level read/write to absolute addresses.
Yes, it is mostly for 710, but write OS function should be working for 800 with
Qcom loader too, just can't test it as i don't have such phone.
Also the Install/Recovery should work forever on a 710, unless Nokia/MS release
some updated bootloader that somehow prevents loading of the signed Qcom
loader and the user does a full flash (or via sneak Zune update) and overwrite
the current DLOAD loader.
BR
Bph&co said:
Hi,
New Beta - 0.47.1 - with ability to write moded OS files(.nb).
OS File button - select .nb file
Write OS button - loads the file onto the last partition (change to OSBL mode first)
oh man you are a superstar. you did what i said it was missing. no more (hopefully) screwd phones.
@Mods please make this sticky.
Click to expand...
Click to collapse
Amazing tool!
I just used it to load Full Unlock Image for Lumia 710 by lucifer3006!
No more linux stuff needed, this is great and almost one-click windows solution!
Thank you!
When we talking about copy moded nb file into partition You mean sdx9 is default partition?
Hi,
The sdb thingi is something from Linux. On low level there are 4 primary partitions
in MBR, all the rest are logical, so the last entry in MBR points to the first logical one,
that for itself contains primary part and next one is logical as well. The last entry
in this linked list is the OS partition.
BR
1. OK I went through this. Tell me please how is possible to unlock bootloader if Lumia is in DLOAD mode? NSS can't reconized WP in this mode.
2. In case of relocking bootloader did I need copy Your specific RM803_11w48_prod_raw_nokia_osbl.bin or download an from navifirm?
I hope it's add backup and restore the "DPP.BIN" function!
like this!
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Thank you very much!
djtonka said:
1. OK I went through this. Tell me please how is possible to unlock bootloader if Lumia is in DLOAD mode? NSS can't reconized WP in this mode.
2. In case of relocking bootloader did I need copy Your specific RM803_11w48_prod_raw_nokia_osbl.bin or download an from navifirm?
Click to expand...
Click to collapse
Hi,
1 - Maybe you have Zune running and NSS can't open the port ? Use the kill Zune
services option in NSS please
2 - Yes this specific loader is needed (its extract from an original file) and is hash
checked before writting to the second partition to prevent dead phones
BR
Hi devs,
hoping on help of people who better know about this materia than me, I hope to create a workaround for OTA repair on faulty Iconia B1-A71 from Acer.
In this case we need devs who has knowledge about stock JB and also testers, who has a B1 with problems on installing OTA Updates with "Invalid partition settings" on FAT.
Status:
More and more user of B1 report the problem of updating their device by OTA. It appears to be a mass problem, which Acer has no solution for.
After checking on rooting issues we already know, that there is a difference in dumchar_info between "normal" and "faulty" B1´s:
Android Partition:
http://forum.xda-developers.com/showpost.php?p=40987372&postcount=197
Normal - android 0x0000000026500000 0x00000000020e8000 2 /dev/block/mmcblk0p3
Faulty - android 0x0000000015e00000 0x00000000020e8000 2 /dev/block/mmcblk0p3
Furthermore there is a difference (and this I assume is the problem for OTA routines) on FAT partition:
Normal - fat 0x0000000148638000 0x00000000882e8000 2 /dev/block/mmcblk0p6
Faulty - fat 0x00000001b0a38000 0x00000000232e8000 2 /dev/block/mmcblk0p6
Those who was in charge of rooting the B1 knows, that we have dumped the android partition by dd using the offset shown in dumchar_info.
In this logic it would be impossible to dump a faulty B1 system.img by using the normal offests - you would not "meet the partition/bits", if you use wrong data.
BUT - as we found out it was possible to dump the system.img from a faulty B1 using the offset of a normal B1! User agentdeep confirms a successful root from scratch on Linux base using the normal offsets: http://forum.xda-developers.com/showpost.php?p=40988791&postcount=202
Now my idea:
- According entonjackson pawitp already assume, that the dumchar_info may be wrong, since otherwise agentdeep would have a bricked device. IF we can proof that OTA checks this value - would it make sense to push a corrected dumchar_info through the ENGMODE backdoor? Anyone out there, who is able to save and extract the OTA, to see the routine?
- If it dont work, does it make sense to try a root from scratch on Linux - and fix the dumchar_info afterwards? Is it possible?
- How can I check a report of existing partitions on Android? Do I have to run busybox from terminal, to start fdisk? I would like to validate the partition information inside the dumchar_info...
This subject may be not as hot as a rooting thread - but more and more user report their problem with update errors, and we may help lots of them ... and show Acer, how this work has to be done...
Thank you in advance!
Sub.
I would like to try that procedure enton asked me by replacing 15e to 265 in dumchar_info. But knowing there is no way I can restore my nandroid backup if something bad happens, I will hold for now
Nice to meet you here, agentdeep I was hoping you will join this thread, since you are the one who made me thinking about this solution...
From my point of view the risk of bricking the tab after changing the dumchar_info is ... pretty low. As long as we have a working system you still can switch back to your origin value. But at that point I would also like to get some more background from the Linux masters in here. Currently I have a problem to understand about the dumchar_info - what is it? How it is created? Do I understand right, that it is an output from Linux kernel?
When this file is accessed? On boot? Which result we will have, if we change it? Is it a properties file, used to set up partitions - or just an info? IF it is only an information we can change it without any fear...
https://github.com/ameer1234567890/...To-Gather-Information-About-Partition-Layouts
This page gives us the information, that "fat" is not just the format - it is the internal memory on MTK based devices. Which finally gives me more inscentive to believe that we have an issue with 8gb and 16gb versions. On that I have seen a thread in a different forum, where a user reported to have opened the B1 and found out that there were 16gb internal memory instead of 8gb as shown in the device properties.
Probably we have "masked" 16gb-versions declared as 8gb???
alba81 said:
Nice to meet you here, agentdeep I was hoping you will join this thread, since you are the one who made me thinking about this solution...
From my point of view the risk of bricking the tab after changing the dumchar_info is ... pretty low. As long as we have a working system you still can switch back to your origin value. But at that point I would also like to get some more background from the Linux masters in here. Currently I have a problem to understand about the dumchar_info - what is it? How it is created? Do I understand right, that it is an output from Linux kernel?
When this file is accessed? On boot? Which result we will have, if we change it? Is it a properties file, used to set up partitions - or just an info? IF it is only an information we can change it without any fear...
Click to expand...
Click to collapse
1st, thanks for the thread! It's really been time to create one for this issue.
I will put a link on the 1st post of my thread to this one, for people experiencing this issue.
Regarding agentdeep, I also think changing the dumchar_info won't brick the device. But we should first make sure it won't brick.
Although I'm using Linux for like 10 years now, I cannot help a lot at this moment.
But if there will be a solution, I will put it immediatly into my toolkit
So, I made a small calculation for the offsets, and this seems to confirm a wrong information in the dumchar_info:
Normal B1 Offset Android size:
Hex: 26500 Dez: 156928 Multiplied with 4096=642777088 Divided by 1024 = 627.712kB
Faulty B1 Offset Android size:
Hex: 15e00 Dez: 89600 Multiplied with 4096=367001600 Divided by 1024 = 358.400kB
If you take into consideration, that the system.img.gz takes (in packed form!) about 350 MB, unpacked even 627,712kB (size of the parition, see above) - then it appears that the information MUST be wrong - if I am right with my calculation...
Following this we have these values for internal memory on both versions:
Normal B1 Offset FAT size:
Hex: 148638 Dez: 1345080 Multiplied with 4096=5509447680 Divided by 1024 = 5.380.320kB
Faulty B1 Offset FAT size:
Hex: 1b0a38 Dez: 1772088 Multiplied with 4096=7258472448 Divided by 1024 = 7.088.352kB
Anyone with 15e can check available space on internal memory? In fact it should be about 5GB as I remember (have the B1 not with me now).
Maybe I am writing complete bull**** here? Anyone can confirm my calculation..??
Thanks in advance!
alba81 said:
So, I made a small calculation for the offsets, and this seems to confirm a wrong information in the dumchar_info:
Normal B1 Offset Android size:
Hex: 26500 Dez: 156928 Multiplied with 4096=642777088 Divided by 1024 = 627.712kB
Faulty B1 Offset Android size:
Hex: 15e00 Dez: 89600 Multiplied with 4096=367001600 Divided by 1024 = 358.400kB
If you take into consideration, that the system.img.gz takes (in packed form!) about 350 MB, unpacked even 627,712kB (size of the parition, see above) - then it appears that the information MUST be wrong - if I am right with my calculation...
Following this we have these values for internal memory on both versions:
Normal B1 Offset FAT size:
Hex: 148638 Dez: 1345080 Multiplied with 4096=5509447680 Divided by 1024 = 5.380.320kB
Faulty B1 Offset FAT size:
Hex: 1b0a38 Dez: 1772088 Multiplied with 4096=7258472448 Divided by 1024 = 7.088.352kB
Anyone with 15e can check available space on internal memory? In fact it should be about 5GB as I remember (have the B1 not with me now).
Maybe I am writing complete bull**** here? Anyone can confirm my calculation..??
Thanks in advance!
Click to expand...
Click to collapse
Yeah internal space is 5.12 GB like posted here in bullbrands post:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Note: this is after swapping internald and external sd...
The calculation looks good, but i don't know why the f... you multiply with 4096 and divide by 1024... I'm working as a developer and now I really feel stupid, because I really just don't know.
entonjackson said:
The calculation looks good, but i don't know why the f... you multiply with 4096 and divide by 1024... I'm working as a developer and now I really feel stupid, because I really just don't know.
Click to expand...
Click to collapse
Dont worry I could explain as follows: 4096 is the qty of bits you write at once on dd, and 1024 - logically to convert bits to KB.
Well, so we see that nothing is right in the dumchar_info, at least on Android and FAT partition, on faulty B1´s. Now we know there is a mistake - and need to validate the right offsets. Anyone has experience with fdisk on Android? Do I have to run it from busybox from terminal emulator?
And can anyone experienced tell us the specifications of dumchar_info? I found out it is a MTK-own chart, which is not existing on other CPU based devices .... which means for me - it can not be that critical in regards to format table, right?
On a rooted device - can we use a log to see when the dumchar_info is triggered?
alba81 said:
Dont worry I could explain as follows: 4096 is the qty of bits you write at once on dd, and 1024 - logically to convert bits to KB.
Well, so we see that nothing is right in the dumchar_info, at least on Android and FAT partition, on faulty B1´s. Now we know there is a mistake - and need to validate the right offsets. Anyone has experience with fdisk on Android? Do I have to run it from busybox from terminal emulator?
And can anyone experienced tell us the specifications of dumchar_info? I found out it is a MTK-own chart, which is not existing on other CPU based devices .... which means for me - it can not be that critical in regards to format table, right?
On a rooted device - can we use a log to see when the dumchar_info is triggered?
Click to expand...
Click to collapse
Ah I see. very easy. so bs=4096 is blocksize and well ok 1024 I already guessed could be convertion from bits to bytes. alright.
Then I would say, yes. the calculation makes sense indeed.
Now we only need someone that tries to write the right parition info into dumchar_info.
volunteers hands up! :victory:
entonjackson said:
Now we only need someone that tries to write the right parition info into dumchar_info.
volunteers hands up! :victory:
Click to expand...
Click to collapse
The biggest problem on that point is - you need to have either root, or do it by obtaining "temporary backdoor root" through ENGMODE. And the qty of user having root on faulty B1 is still pretty low...
alba81 said:
The biggest problem on that point is - you need to have either root, or do it by obtaining "temporary backdoor root" through ENGMODE. And the qty of user having root on faulty B1 is still pretty low...
Click to expand...
Click to collapse
i know busybox has fdisk binary.
adb doesn't know fdisk?
Where can I call it thru ADB?
Starting busybox from internal memory thru Terminal Emulator also makes me problems ... permission denied.
alba81 said:
Where can I call it thru ADB?
Starting busybox from internal memory thru Terminal Emulator also makes me problems ... permission denied.
Click to expand...
Click to collapse
There is none. I thought fdisk comes with adb, but... no.
But maybe we need no fdisk. If i understood it right, wie only must edit the dumchar_info so the system "believes" it has the right partitions again.
Yes, obviosly the update process checks this value. As you already checked the /proc/emmc shows different values, and /proc/mtd is empty. /proc/partitions contain different information type.
Before changing an important value I think we need to validate that any change in dumchar_info remains after reboot, since the update failure notification appears in recovery mode during update - right?
Edit:
I do not get access to dumchar_info. Going through ES File Manager I set the properties, and even it shows after changing its saved - its not. How can I get the rights? And how I can take the rights for system away to not be able to access it any more? Each time I open the properties of it I see a different date ... is it in permanent access?? Or do I need a different file Explorer?
Edit2:
Wikipedia is my friend. Ok, now I know - dumchar_info is a procfs, generated by the kernel during boot and not saved. So I am affraid ... we are stuck on a faulty kernel issue?
Where does the kernel gain this Information from during boot? Anybody an idea?
I hope this helps
agentdeep said:
I hope this helps
Click to expand...
Click to collapse
Thank you - I will validate later on, once I am at home ... have now only my n8000 with me.
Ok, checked - my version is the same, except:
[email protected] (after Linux version 3.4.0)
which I think can not be that important, since all other release data is similar. So it is not the kernel we have to fight with - at least...
Ok, so following on this subject we need to see what comes up in the future:
http://forum.xda-developers.com/showpost.php?p=41168837&postcount=295
At least the reason seems to be confirmed from Acer site - a faulty format which is reported.
IMHO it can not be only the update with the problem, the device itself reports a different format in dumchar_info, not the update.
Well - we´ll stay tuned...
hi there,
i have a faulty B1 with root....also i tried the Factory Reset Workaround several times, it does not work for me....everytime about 10-15% i got the message "partition error...bla".
So if you want me to to test things...go on
I'm new here, however I successfully rooted my device using the "toolkit" even though I have
Code:
Faulty - android 0x0000000015e00000 0x00000000020e8000 2 /dev/block/mmcblk0p3
Thanks to Enton.
My internal storage is reported to be just 5.17GB (not 8GB as expected) confirming the figures in a previous post.
I complained to acer support about the size of the internal storage being nearly 3GB short of what it should be and that I thought it was down to a "memory allocation error".
There response was " As you have mentioned in the previous e-mail internal storage shows as a 5.17GB, I would like to inform you that the other space of the unit is occupied by Android Operating System, customer will not be able to use the complete 8GB from the unit, as Operating system needs a space. "
Is this complete and utter BS? I understand 4.1.2 Jelly Bean is just over 200MB.
Can someone please confirm.
BTW if any dumps are required from my "faulty" device (I do not have the partition error though) I'm happy to try.
BTW2 I've installed the new PMTUpdate patch "FixG1PMT" and that did nothing for my problem.