Related
How to replace the ADVENT logo on the boot screen.
The screen resolution is 1024x600.
How to replace your Boot Screen:
Create and save your bootscreen as a PNG (if it is smaller than 1024x600, your bootscreen will be centered, transparency will result in the ANDROID boot glare effect).
1. Connect your Vega to your PC's usb.
2. Turn USB Debugging on in the Applications menu.
3. In command prompt / terminal, browse to the directory containing adb.exe, type:
Code:
adb-windows pull /system/framework/framework-res.apk /framework-res.apk
This will copy the framework-res.apk from your Vega and save it in the directory adb.exe is located.
4. Open framework-res.apk in WinZIP / WinRAR or similar and browse to /assets/images/
5. Replace android-logo-mask.png with your bootscreen and save the apk in the same format, overwriting the original.
6. In your already open command prompt / terminal window type:
Code:
adb-windows remount
adb-windows shell rm /system/framework/framework-res.apk
adb-windows push framework-res.apk /system/framework/
7. Reboot your Vega.
********* Reducing the file size *******************
If you want to reduce the file size of your new framework-res.apk file, you could delete the following files from /res/drawable/:
nvidia_wallpaper01.jpg
nvidia_wallpaper02.jpg
nvidia_wallpaper03.jpg
nvidia_wallpaper04.jpg
nvidia_wallpaper05.jpg
nvidia_wallpaper06.jpg
nvidia_wallpaper07.jpg
nvidia_wallpaper_dual01.jpg
nvidia_wallpaper_dual02.jpg
nvidia_wallpaper_dual03.jpg
nvidia_wallpaper_dual04.jpg
nvidia_wallpaper_dual05.jpg
nvidia_wallpaper_dual06.jpg
nvidia_wallpaper_dual07.jpg
Also you can remove all *.ogg from the following directory /system/media/ringtones
Boot Screens:
File name: Advent_Vega_Leather.jpg File size: 235.60 KB
File name: android3d.jpg File size: 366.66 KB
File name: Androidboot.jpg File size: 1.24 MB
File name: androidlogomask.png File size: 807.17 KB
File name: Androidwall.jpg File size: 136.15 KB
File name: Android_green.jpg File size: 123.04 KB
File name: Android_logo.jpg File size: 86.83 KB
File name: android_logo_mask.png File size: 18.18 KB
File name: android_logo_mask2.png File size: 40.21 KB
File name: boot.jpg File size: 1.25 MB
File name: Bootphotoshop.jpg File size: 337.77 KB
File name: Bootphotoshop2.jpg File size: 337.44 KB
File name: Bootphotoshop3.jpg File size: 354.39 KB
File name: Bootphotoshop4.jpg File size: 233.84 KB
File name: stealboot.jpg File size: 513.15 KB
File name: Vega_Black_Leather.jpg File size: 434.97 KB
File name: Vega_Glow.jpg File size: 321.36 KB
File name: wallpapergrey.jpg File size: 77.28 KB
******** Thanks to JordanT92 who provided the original information.
******** And boffboff, remlap, morchuboo, arad85, wobblydoggy, Higgsy, donalkeane from MoDaCo who provided the graphics.
@percy25 - are you just copy/pasting all this stuff from the modaco forums?
Everytime I come and refresh here, it seems there's another thread with the same info...
At least give some credit to the users from other places, who've done the work already?
monkeyboy451 said:
@percy25 - are you just copy/pasting all this stuff from the modaco forums?
Everytime I come and refresh here, it seems there's another thread with the same info...
At least give some credit to the users from other places, who've done the work already?
Click to expand...
Click to collapse
Good point Monkeybot451, Updated Post.
I have moved my Post "Advent Vega - ROMs / Software Updates / Guides / How Tos, Links to ROMs, Flash Updates, Guides, Misc apk's" from Modaco to here as from now will only be maintaining it here.
percy25 said:
Good point Monkeybot451, Updated Post.
I have moved my Post "Advent Vega - ROMs / Software Updates / Guides / How Tos, Links to ROMs, Flash Updates, Guides, Misc apk's" from Modaco to here as from now will only be maintaining it here.
Click to expand...
Click to collapse
Seriously that just sucks and I think unfair I honestly don't see this community growing the numbers MoDaCo has.
Good luck with it though but these kinds of attitudes make me dislike this forum. Seems like cutting and running for no reason to me.
remlap said:
Seriously that just sucks and I think unfair I honestly don't see this community growing the numbers MoDaCo has.
Good luck with it though but these kinds of attitudes make me dislike this forum. Seems like cutting and running for no reason to me.
Click to expand...
Click to collapse
I didnt mean to upset anyone!
I have just found the XDA Developers fourm more open to development as its free to all (Instead of the charging scheme modaco uses). I believe updates should be available to all for the community to benefit.
To keep everyone happy I will maintain both post to benefit all.
Hi Percy, yeah thats true, still you don't have to pay MoDaCo still use the forums I honestly like the idea of two separate forums doing different things that I can take the best from both and hopefully contribute where I can
Cheers mate
Please note that this is a very easy way to lock your device.
I tried to change my boot screen and got stock in booting due to "insufficient disk space" issue, and had to reflash the device.
Harplo said:
Please note that this is a very easy way to lock your device.
I tried to change my boot screen and got stock in booting due to "insufficient disk space" issue, and had to reflash the device.
Click to expand...
Click to collapse
True, I been in that situation many times. I sometimes find if you use a "adb shell rm" command to remove old framework.apk first, this can help.
percy25 said:
I have just found the XDA Developers fourm more open to development as its free to all (Instead of the charging scheme modaco uses). I believe updates should be available to all for the community to benefit.
Click to expand...
Click to collapse
Could not agree with your more. Welcome to xda dev, hope we can all do great things to are vegas.
You are keeping me happy with all of your useful info. Helped loads with the performance pack. Thanks
I have updated the attached framework-res.apk to include the following:
Android Boot Screen
Battery Colour changed to Blue (instead of Green by default)
Removed the Nvidia Wallpapers to keep file size down.
Link to File:
File name: framework-res.apk File size: 6.49 MB
See the first post for instructions on how to install.
I know this is a pissed off issue by many of you but I want to use my archos as an industrial tablet.
I've made a fancy boot animation but there is still the Archos entertainment your way logo at early boot.
I read about it at an archos gen5 thread that with aos-tools and the famous flash binary the logo can be altere to another 800x480 logo by flashing with the 0x060000 starting address. Other threads said that this works no more so I turned to the data/customization way but here the early logo is problem for.
A solution could be to wipe out and to have animation only at late stage. Is it possible somehow?
br, sodjas
Update:
I successfully compiled the flash utility:
http://code.google.com/p/aos-tools/
But ran into the problem the it needs flashrw.ko module.
I found it on openAOS site but unfortunately it is compiled for gen5 armv5 the load fails with vermagic assert error.
I read on archosfans forum thread that flashrw.ko is non public and confidential thing but it only contains a bunch of ioctl calls.
I disassembled it and it showed that it is made of intel_flash_cmd.c file.
Could anyone help me how to get the flashrw.ko module for armv7-a?
Sad news modinfo shows:
alias: char-major-10-243
license: Proprietary
description: flashrw
author: Archos
depends:
vermagic: 2.6.10_mvl402 ARMv5 gcc-3.4
It is Proprietary
Hi sodjas,
you should do a little more research on this issue.
sodjas said:
I've made a fancy boot animation but there is still the Archos entertainment your way logo at early boot.
I read about it at an archos gen5 thread that with aos-tools and the famous flash binary the logo can be altere to another 800x480 logo by flashing with the 0x060000 starting address. Other threads said that this works no more so I turned to the data/customization way but here the early logo is problem for.
A solution could be to wipe out and to have animation only at late stage. Is it possible somehow?
Click to expand...
Click to collapse
As you started to point out, there are different bootlogos for the differnt stages on start-up.
1. bootloader logo
2. ramdisk bootlogo
3. Android logo (animated)
The logo inside Android could be easily removed or replaced (at least using Urukdroid).
Also the ramdisk logo could be modified with some technical skills (ramdisk needs to be rebuild and replaced).
Replacing the first hardcoded bootloader logo, is something for the freaks, but in fact it is possible.
First of all you'll need read/write access to the mtd block devices created by the kernel. This would require at least SDE or Urukdroid installation.
The Archos tablets use embedded MMC as persistant storage.
All partitions of this device are mounted as block devices and could be tweaked by directly accessing them (e.g. using dd for low level access).
One could start by reading some sectors of the first raw partition, examine the structure, do some disassembly and find the location where the bootloader logo is stored. Not sure if it could be deleted without changing some lines of code.
In fact this is an expert thing, if something goes wrong, you'll have a true brick .
There'd been some posts around covering this topic.
sodjas said:
Update:
I successfully compiled the flash utility:
http://code.google.com/p/aos-tools/
But ran into the problem the it needs flashrw.ko module.
I found it on openAOS site but unfortunately it is compiled for gen5 armv5 the load fails with vermagic assert error.
I read on archosfans forum thread that flashrw.ko is non public and confidential thing but it only contains a bunch of ioctl calls.
I disassembled it and it showed that it is made of intel_flash_cmd.c file.
Could anyone help me how to get the flashrw.ko module for armv7-a?
Click to expand...
Click to collapse
AFAIK, there's no need for this kernel module on gen8 devices.
The gen8 devices do not use any raw NOR flash or NAND devices.
All access to the eMMC is done with mtd kernel driver using the OMAP mmc interface.
BTW there might be some parts of storage used as hidden sectors, but this is a kernel thing only.
But back to topic:
In fact you'll need to find the bootlogo in raw data of the bootcode, determine the format and replace the raw blocks of memory.
Maybe you'll also need to tweak the security checks in bootcode as well, because checksum will change is the bootlogo is replaced.
Anyway it's slightly difficult to do so, but it's not impossible
Have fun,
scholbert
Lot of interesing information thank you, I'll check the hints out... The checksum thing sounds serious
Anyway, thank you very much for your answer it contains a lot interesting and useful things for me!
br, sodjas
Hi sodjas,
you're welcome!
This might be of interest to:
http://forum.xda-developers.com/showthread.php?t=1018260
This guy already made a disassembly of boot code.
http://forum.xda-developers.com/showthread.php?t=1214674
This guy wrote some tools for mmc low level access.
Maybe they might help you as well.
Keep on posting, this is an interesting topic
Regards,
scholbert
@sodjas:
Just being curious, why do you want the archos as an industrial PC?
I'M asking because we have bought a very cheap development board
http://embedded-computing.com/low-runs-main-line-linux-android
where you can install everything you want.
It is definately not as powerfull as the archos, but it costs less then half of it.
And if you search for OK6410 you will find others that even have the Android 2.3 for that.
@scholbert:
Thank you very much one more time , hope we can bring out something interesting
@fzelle:
The answer for this is the circumstance when you are at a software development deparment surrounded with high level software guys and have an interesting and impressing task to build an RFID enabled industrial terminal with WIFI capability and a platform where you can easly build fancy touch based UI-s in just 3 months then you made choices like these -> to have a proof of concept thing -> to prove that your software is unique and feasible to develop -> to be able to go to exhibitions to make this interesting to investors -> later it is more then possible that we will say somebody who has the experience in hw building: OK we have this HW build us a similar one from OEM parts bundled in an industrial box...
@both:
Thank you guys for replying, this is such a nice community!
br, sodjas
Hey Guys!
This is what I've done:
1. studied the linked threads by scholbert
2. used the extended aos-tools and successfully extracted .aos file
3. now I'm seeing a:
Code:
-rw-r--r-- 1 root root 432 2011-10-10 17:21 digest
drwxr-xr-x 2 root root 4096 2011-10-10 17:21 raw
-rw-r--r-- 1 root root 10 2011-10-10 17:20 repack.sh
drwxr-xr-x 3 root root 4096 2011-10-10 17:20 root
-rw-r--r-- 1 root root 10 2011-10-10 17:20 unpack.sh
structure.
If I understood right scholbert the ramdisk is under root/data/androidnerged.squeashfs.secure
How can I manipulate this part?
How can I rebuild the ramdisk?
If I understand correct the GPL released part is only the initramfs and the kernel itself...
Another question is that the most interesting thing here for me is the aos-fix tool
What is the:
Code:
--clear-signature Clear the signature out of a SIGN block, or a flash segment header.
part excatkly good for?
Sorry for the lots of questions, I'm still very green on low level
br, sodjas
One more thing:
I have the following structure under raw:
Code:
-rw-r--r-- 1 root root 264 2011-10-10 17:21 11_EXT2
-rw-r--r-- 1 root root 264 2011-10-10 17:21 15_EXT2
-rw-r--r-- 1 root root 8 2011-10-10 17:20 4_EXT0
-rw-r--r-- 1 root root 3264456 2011-10-10 17:20 7_MMCF
-rw-r--r-- 1 root root 2878728 2011-10-10 17:20 8_MMCF
I guess 7_ and 8_ MMCF files are the interesting ones...
Can I find a desc about these because in vitalif's thread about tweaking the bootloaders he tells about mmcblk0 / 1 ...
I also wasn't be able to find the hex parts found by scholbert when he linked vitalif's thread...
Still very confused but keep on learning
br, sodjas
Of course i understand that, i'm a sw dev for 25 years.
I was lucky to see that board before we had some similar needs as you have.
What do you use for the rfid part?
Hi sodjas,
it's late but i'll try to answer your questions
sodjas said:
This is what I've done:
1. studied the linked threads by scholbert
2. used the extended aos-tools and successfully extracted .aos file
3. now I'm seeing a:
Code:
-rw-r--r-- 1 root root 432 2011-10-10 17:21 digest
drwxr-xr-x 2 root root 4096 2011-10-10 17:21 raw
-rw-r--r-- 1 root root 10 2011-10-10 17:20 repack.sh
drwxr-xr-x 3 root root 4096 2011-10-10 17:20 root
-rw-r--r-- 1 root root 10 2011-10-10 17:20 unpack.sh
structure.
Click to expand...
Click to collapse
So this is the firmware structure before it is installed on the device.
The update process is done by the bootcode and there's not that much information about it and not much we could actually do with these files.
So you'd better have a look at the installed partitions and the way to modify thoose.
sodjas said:
If I understood right scholbert the ramdisk is under root/data/androidnerged.squeashfs.secure
How can I manipulate this part?
How can I rebuild the ramdisk?
If I understand correct the GPL released part is only the initramfs and the kernel itself...
Click to expand...
Click to collapse
No, the squashfs file is the final rootfs mounted as a loop device by the stock firmware.
It's possible to modify this file, but if you do the checksum won't match and you'll have to tweak bootcode to ignore security checking.
So in fact this is not very comfortable, but doable.
The ramdisk is the the cpio file archive also beeing updated and included in the update. Don't know the structure right now because it's on my linux laptop.
sodjas said:
Another question is that the most interesting thing here for me is the aos-fix tool
What is the:
Code:
--clear-signature Clear the signature out of a SIGN block, or a flash segment header.
part excatkly good for?
Click to expand...
Click to collapse
I don't know this tool and i guess it has been made for the older platforms.
sodjas said:
One more thing:
I have the following structure under raw:
Code:
-rw-r--r-- 1 root root 264 2011-10-10 17:21 11_EXT2
-rw-r--r-- 1 root root 264 2011-10-10 17:21 15_EXT2
-rw-r--r-- 1 root root 8 2011-10-10 17:20 4_EXT0
-rw-r--r-- 1 root root 3264456 2011-10-10 17:20 7_MMCF
-rw-r--r-- 1 root root 2878728 2011-10-10 17:20 8_MMCF
I guess 7_ and 8_ MMCF files are the interesting ones...
Can I find a desc about these because in vitalif's thread about tweaking the bootloaders he tells about mmcblk0 / 1 ...
Click to expand...
Click to collapse
Yeah, as i pointed out:
By extracting the update file you got an "external view" of the system.
After the firmware is placed on the device these files are flashed to eMMC and got mounted as block devices.
So it's little different then.
sodjas said:
I also wasn't be able to find the hex parts found by scholbert when he linked vitalif's thread...
Still very confused but keep on learning
Click to expand...
Click to collapse
It's a bit complicated to explain... but quite easy in the end.
You'll have to read out the partitions as raw blocks.
All the low level stuff is mounted as /dev/block/mmcblk0p1
Please read out first using the dd command.
It will give a file at about 32MByte, ands it's all cryptic binary format (rawfs and below).
So if you like to enter this, there's not much information here and you'll have to digg out pieces.
Maybe it's better to modify the higher level parts...
Anyway, the very first bootlogo is called banner. The format is unkown, at least to me, and you'll have ot understand the rawfs file structure used by Archos.
Attached you'll find the mounts of stock and Uruk firmware.
I know that this is little abstract right now, but i'll have to take some sleep
Have fun!
scholbert
@fzelle:
the rfid part is for workflow monitoring in glass houses. we would like to deploy N terminals in each house and the workers can check-in, define a task they are working on and after they've finished can check out... simple but all info is gathered on a central place and is in order to make easier planning/observing/and calculating financial/investment related things...
the only problem is the musb_hdrc.ko -> it is not picking the FTDI chip if its plugged-in with the OTG cable at the same time. It is a known issue but I still have a lots of problem here:
1. if a change musb_hdrc.ko to my instance musb_hdrc.ko in /lib/modules it is not working at all, if I check it with modinfo it is different than the one in the GPL release. I guess these files under /lib/modules are also proprietary
2. I degbugged around and saw that the state changes for musb only work well if you first attach the OTG micro which has a grounded 5th pin ->then the state goes to a_idle and then attach the FTDI chip -> this is a working scenario
3. If you attach the OTG with already connected FTDI then it stuck at b_idle mode...
I started a thread about this:
http://forum.xda-developers.com/showthread.php?t=1288522
but it seems the proprietary drivers will be the root of the problem here...
@scholbert:
a mininum thing I owe you is a beer a lot of useful infos here again I'll check around and come back if there are some updates.
thank you guys!
br, sodjas
Hi,
thanks for appreciating.
But stupid me, i forgot one thing...
Quoting myself:
Anyway, the very first bootlogo is called banner. The format is unkown, at least to me, and you'll have ot understand the rawfs file structure used by Archos.
Click to expand...
Click to collapse
So there's a kernel driver for rawfs of course
The rawfs parts got mounted to /mnt/rawfs and present themselfs as files (avboot, banner,...).
No need to fiddle with the raw binaries to investigate the structure.
You'll have to be root to access this directory.
I'll do some research about the file format of the banner file
EDIT:
O.K., here we go... it is a gz compressed file representing raw pixel data.
So in fact this is the very first boot logo!
Should be possible to import this file to gimp or something.
Don't know if it breaks the avboot security check if it get's replaced. So please be careful!
EDIT2:
I got a Archos 101 so filesize will vary on other platforms.
The pixel data is put into 32bit format so each pixel requires a 4-byte value.
On A101 the resulting file size is of the uncompressed banner file is 2457600 bytes -> 1024x600x4
The simple framebuffer inside avboot uses only the lower 24bit of 32bit pixel data.
The most significant byte of each pixel is always set to 0xFF (0xFF000000 written as MSB first)
To completely blank screen (delete archos logo) you'll need to blank out all pixel.
Pixel data should look like this:
Code:
0xFF000000 x 1024 x 600 (for A101)
0xFF000000 x 800 x 480 (for A70)
You might create such a file with a hex-editor or use some scripting.
Good luck with your USB driver stuff!
Regards,
scholbert
Update
I modified both mmcblk0 and mmcblk0p1, my tab is still booting.
The modification of /mnt/rawfs/banner directly was my idea too, but I'm still afraid of some parts
I pulled the banner file and on ubuntu I can list the content, but can't extract it, and there are lots of questions like:
1. The file inside banner is named i240x400 -> this means that it is a 240x400 image but it would be more logical that it is 400x240 based on how "Entertaiment your way " looks...
2. Ubuntu's file roller can't extract it
3. When I open it in hex editor it has some meta info at the start of the file
and a question at the end:
How did you uncompress your banner file? I always get errors, maybe I used wrong syntax...
br, sodjas
Hi Sodjas,
Let me jump in on this to complement your study:
First, a BIG WARNING: touching any of this without patching signature check will result in bricking device.
Second BIG WARNING: Vitalif's mmc offsets for bootloader patches are valid for his device only. Mine has completely different values, I presume there are multiple bootloader versions out there. If patch is incorrect, or not done in the right order, instant brick.
7_MMC and 8_MMC are indeed interesting parts, these are the kernel+initrd images for android and recovery.
As stated by scholbert, to get a better understanding, you should take a look at /mnt/rawfs:
You'll see few files there:
avboot (second stage bootloader)
init (normal boot android, kernel+initrd)
recovery (recovery boot, kernel+initrd)
custom (sde boot, kernel+initrd)
banner (boot logo as it seems)
7_MMCF is flashed to init
8_MMCF is flashed to recovery
Splitting these files into zImage+initrd.gz is quite easy, I can give you some hints if you want. But I don't think it would serve you much for what you're trying to do: what you want is changing bootloader logo, so your goal is avboot+banner.
But again, don't modify anything on mmc0 until you're sure of what you do. First bootloader checks avboot signature and avboot checks init and recovery signature for sure. Without patch, you'll brick your device.
I don't know if avboot checks banner file though.
Hi Letama,
Thank you for joining.
Yes sure you are right the values vitalif mentioned were on different addresses BUT occured only once in the whole binary for both binaries, so I tried my luck and I think it is working because after reboot I have mmcblk0 and mmcbl0p1 still with the patched content and the tab boots without any problem
If I'm right then now I can start playing with altering mmcblk0p1 content because I have patched verify_hash function. Am I right?
Two big questions still open for me:
1. How to modify banner in an efficient way?
2. I understand now I have two patched bootloader binaries and can dd them on any A70IT, am I right or the patching process needs to be done/ device? I suppose not.
Update 2
In the meantime I uncompressed it on win with 7-zip I see the content I should modify to 0xFF000000 but I'm still not sure how flush this to all 0xFF000000 because there is some meta info at start. And as second, how to compress it, maybe the gzip -9 i240x400 will do its job as it was described at Gen5 boot logo tutorial...
br, sodjas
sodjas said:
because there is some meta info at start.
br, sodjas
Click to expand...
Click to collapse
Sorry AFAIK, no metainfo, just the pure 0xAABBCCDD 32bit values as scholbert told me before, sorry for that
br, sodjas
I realized again I'm a fool, or just archos guys wanted to make a joke
1. the banner file is named i240x400 BUT
2. when you extract it you got a 1 536 000 bytes sized file
3. I used my awsome maths skills and found out that: 1 536 000 / 4 <byte> = 384000 / 800 <pixels> = 480
So the raw image size is 800x480 and no 240x480 as the file name indicates...
I just need to flush 0xFF000000 384000 times in a file I think.
br, sodjas
sodjas said:
Yes sure you are right the values vitalif mentioned were on different addresses BUT occured only once in the whole binary for both binaries, so I tried my luck and I think it is working because after reboot I have mmcblk0 and mmcbl0p1 still with the patched content and the tab boots without any problem
Click to expand...
Click to collapse
Yes, search pattern was the same for me too, only different offsets. Good thing that code didn't change.
sodjas said:
If I'm right then now I can start playing with altering mmcblk0p1 content because I have patched verify_hash function. Am I right?
Click to expand...
Click to collapse
I only modified init and recovery, but I guess they wouldn't implement a specific signature check for boot logo. I'm suspecting that there is no signature check at all on it but I never checked avboot for that.
sodjas said:
1. How to modify banner in an efficient way?
Click to expand...
Click to collapse
To modify init and recovery, I wrote a small app that directly open /dev/block/mmcblk0p1, seek for the right position (with some file signature check to be sure I'm doing it right) then write. I make sure that I don't write a bigger file than current ones and it works fine for init/recovery. I believe that archos flasher does the same as existing file sizes are bigger than the firmware dump file sizes.
For your needs, I don't know if you will have to adjust size in the rawfs directory entry and/or avboot. Rawfs is quite straightforward, you can take a look at linux driver if you need to adjust directory entry.
sodjas said:
2. I understand now I have two patched bootloader binaries and can dd them on any A70IT, am I right or the patching process needs to be done/ device? I suppose not.
Click to expand...
Click to collapse
A dd of mmcblk0 (not mmcblk0p1, you need also first bootloader) should do the trick if the hardware doesn't change and doesn't need a different bootloader. I think that there is multiple revisions of hardware out there, improper bootloader for a specific hardware revision could not boot.
Safest bet would be to write a small patcher that would check pattern and stop if you don't have a known bootloader.
Since going on a little adventure with this, and successfully changing my boot Splash screen, (The ASUS + Nvidia logo before the standard boot animation) I decided to post a guide on how I accomplished this myself.
Thanks: This would not have been possible without the wonderful work of rayman86 for his blobtools, whirleyes for his splash patcher, and gee one for putting up with my total noob questions while I stumbled through this :3
The usual Disclaimer applies here, I'm not responsible for bricks, and if you're trying this with Sbkv2 (Like I did) and mess up, quite frankly you are FOUBAR SOL OCSA!! Be.. Careful. May the force be with you.
This guide was run on a Windows 7 (x64) machine, I was going to use linux, but I couldn't get Blobtools source to compile into something working (since I'm functionally retarted), the commands are pretty much exactly the same though, if you can get blobtools working.
Required files:
1. The latest ASUS update firmware from their site for your region: (I used US .24 firmware) link
2. Rayman84's (Give him thanks!) Blobtools (don't need boottools for just a splash screen change) [Attached] Original thread: link
3. A hex editor, I used xvi32 (you just need to be able to read and compare blobs) link
4. Three Images that you want to patch the splash screen with, the sizes need to be exactly 300x100 (asus logo) 300x90 (below) and 300x30 (Nvidia logo)
Note: Due to the nature of how the image is stored (In the freaking bootloader I might add -_-) these sizes need to be Correct, the bootsplash patcher should help you with this.
5. whirleye's (Give him thanks!) Boot Splash Patcher windows app. (Complete with shiny GUI) link
6. 3 pinches of ground unicorn horn, eye of newt, and hog's blood (extremely important ! ) Link
7. ???
8. Profit
*Make yourself a mental note of the disorganized location of these files as you scatter them throughout your documents/desktop/downloads folders.*
The Process:
1. Unzip the asus update, inside it is another zip, which you unzip. (Okay ASUS, you likes your zips) Inside there is a blob file, don't be alarmed, it will not attempt to absorb you into it's blobbiness, it stands for a Binary Large OBject file.
2. Put blobunpack into the same directory as the blob. (for easy cmd command)
3. MOD4+R (Windows key+R) to open run box, type 'cmd' This doesn't stand for central machine decimator.
4. Navigate to the directory with your blob, it was getting pretty lonely without you anyway. Ex: cd C:/users/username/downloads/blob
5. type blobunpack blob, your blob will now split itself into a multitude of blobs each with its own suffix. You now have to say Blob sr. and blob jr. when addressing them, it's only proper.
5a. You will (should) get:
blob.header (Oddly, I didn't actually get this, but we don't need it so don't worry about it.)
blob.app (huge file, the actual update system.img) [Don't Need]
blob.ebt (bootloader) [Need this blob]
blob.lnx (boot.img) [Don't Need]
blob.sos (recovery) [Avoid like the plague, unless you like losing cwm :3]
Note: The file extentions are 'false', they're just a way of separating the blob into manageable sections, they're all just blobs topped with a fancy-schmancy file extension.
6. Now that the blob has lost some extra poundage, it's time to patch it, Backup the blob.ebt and open the blob.ebt with whirleye's patcher!
7. Use your keyboard (This be old school) to load the images into the blob.ebt, shortcuts are at bottom and the tool is easy to use.
8. Save as patched_bl.bin, this should enable save as blob. (I had to do this for whatever reason, just don't question the gods)
At this point, you *Should* have a ready to patch bootloader with your new fancy image! If you like having a device that doesn't double as a very fancy paperweight, you'll keep going and check with a Hex editor.
9. Open your blob with the hex editor, the first line should be MSM-Radio-Update, followed by some 0s, then it should say EBT at the beginning. This marks which partitions are contained in the blob and will be flashed. Make sure none of the other (.SOS.LNX..etc) are in the blob, as then it would overwrite you. (shouldn't be there if you unpacked properly, and the filesize should be around 1.4KB)
9a. Search for whirleye's watermark, this shows the patcher worked, says "splash patcher by whirleyes"
9b. 9b is a terrorist and was deported by the TSA, move on to 9c. (bad hex joke)
9c. Open the backed up Asus blob.ebt you unblobbed, and compare the two files a tad, they should be nearly identical in length and code, except for the patched image section. If everything checks out you should be ready to flash your shiny new boot splash!
10. Now take your blob.ebt and De-knight it, stripping it of it's file extension. It is now just a 'blob' again.
11. Connect your tf and put it somewhere on your internal or external SD using adb or mass storage or whichever (I used /Removable/MicroSD/blob9000/blob)
12. --
gee one said:
to flash using the staging partition- you need either terminal or adb access.
the commands are:
su
dd if=/your/blob/here of=/dev/block/mmcblk0p4 # the last chars are zero pee four
reboot
Use adb or file manager or magic to save your blob somewhere on your transformer.
As it reboots, you should see a blue progress bar to indicate that it is flashing. It will reboot again and hopefully you will see your new splash screen.
Click to expand...
Click to collapse
13. ???
14. Profit!
Attached files:
Blobunpack.exe (zipped)
The Blob.ebt (zipped) finished product I made. For the US .24 update ONLY RAHHHHHH!!!!(Portal gun, aperture logo, mizore-kun. LD)
The blob.ebt.asus (zipped) original unblobbed .ebt part From the US .24 update (For all dem 'muricans)
Chuck Morris.png (A picture of a trollface, yes.) [Zipped]
Any questions? Let me know if this works out for you, worked wonderfully for me!
Link to my Q&A thread, may help with a little understanding, also has pic of my patched screen: link
If I helped, hit yo' self some thanks button. :3
Looks like you're fully explained how to do it and where to get the tools (which can often be harder than finding the how to info) but I've got to ask. Isn't that tons of work just to change something that shows for like a minute once a month whenever you reboot your tablet? I guess I don't understand why to do this but am trying to.
Sent from my PG41200 using Xparent Purple Tapatalk 2
Well, it's more of a, BAHAHAHAHAHAH I DID IT IN YO FACE! Sort of thing, and a neat challenge if you want to mod your tab a bit more. I did it more for the challenge of doing it than anything else. I also hated having everything EXCEPT splash completely customized. Just a proof of concept, and like a 30-40 min thing, not terrible. Let me know if you give it a shot
This is the complete open source evolution- ask some questions, do some research, flash something cool, and then write the guide. All you need now is the t-shirt. Congrats! We need more people willing to explore and ask questions.
sent while running with scissors
It's been a while since I made the discoveries.
Back then, I even made an android app to change the splash easily, but I never upload it to public.
Bump this thread if anyone interested.
I think I still have the source code buried deep inside my pc.
That'd be neat, the current method works but may be a tad confusing for some. I'll test out if you'd like
Has anyone done this successfully?
Flawless!
Works perfectly for me on:
TF101-A1 (16GB) B70
Android 4.0.4
Megatron ROM 1.1.6 (ricardopvz)
I don't think those last two matter, since this is a bootloader, but I thought I'd include it just in case.
I cannot express my thanks enough. If I had any skill, I'd create a CWM flashable template for this mod to make the flashing process a little easier.
I could do that, but that would encourage laziness, and noone would learn the Process behind it all. Which is the real whole point of this experiment :]
Hello!
This is my first time posting, i normally am able to solve problems by looking through the forums, but this time not so i created an account and posted.
Any help that could be offered would be greatly appreciated.
The Story:
I have had the nook for around a year running CM7 or CM9, and last semester i took a programming class and programmed apps for android and ran them on my nook. i got acquainted to adb and am somewhat familiar with it. i remember when i started the serial number which adb used to Id the device was normal, but then around halfway through it simply became a string of zeros. so that is when the device lost its serial number I assume. Sadly this is not the main issue.
A week or so ago i was attempting to return my nook back to the stock Rom, and got it booting fine but it would not register because it was missing the serial number and Mac address. I looked through the forums and tried to fix it. i figured out it was stored in partition 2. looking in to it i could easy reflash other roms and they would work fine, and i tried restoring an old backup i had, which did not fix the problem ( i didn't think they affect that partition at all). eventually i stumbled upon lepinars repair partitions zip, and with nothing else working, i flashed the repair partition 2 zip in hopes the backup from partition 3 would have the correct serial number in it and restore the serial number. This put my device in a recovery bootloop. i am able to boot into cwm and talk to the device over adb, and i can flash new roms, but it will ONLY boot into recovery, no matter what rom it is ( i have tried CM7, CM9, sdcard install of CM7, and stock 1.0.1) . i figured out that it is because of a file on the mmcblk0p2 which i think was BCB, but there might be some other things affecting it.
So now you know what has happened, can anyone help me? I would like to get a Rom to boot into the normal mode, and then restore serial number / mac address so that it could be registered.
Once again, Thank you so much.
The problem is that without a valid serial number on partition 2, no rom will boot even if the recovery flag is set properly. It will just keep going to recovery.
If you have adb working, look at p2 and see if you have a devconf folder. If you do, look in it to see what files are there. There should be simple text files that have data in them. Like SerialNumber that has a 16 digit serial number in it (but the file is 17 bytes long so must have a linefeed on the end.) MACAddress is another, with a 12 digit number and no linefeed. 17 files total. All of them with rw-rw---- permissions.
Those files are usually backed up in partition 3 in a file named rombackup.zip. Unzip that zip manually and place them all in the devconf folder in partition 2. Set permissions as above.
Also you said you flashed my repair zip. Did it give you the message that it completed successfully? I have it set to abort if everything is not right.
Edit: Your serial number is stamped on the little flap that covers the micro SD card. It is also on your box the NC came in. If you cannot find the SerialNumber file in the backup zip, you could try manually creating it and putting in the right place.
Thanks. A week ago i was more familiar with this because i had just done a day or two of reading, but sadly a bit has slipped my mind.
ADB is working just fine when i boot into CWM, but i am having trouble finding partition 2. For some reason I recall a rom folder on the root level, but when i do an ls while in adb shell, all i see is this:
boot etc sd-ext
cache init sdcard
data init.rc sys
datadata proc system
default.prop res tmp
dev root ueventd.goldfish.rc
emmc sbin ueventd.rc
more random info still in adb shell)
when i do an fdisk -l /dev/block/mmcblk0
Disk /dev/block/mmcblk0: 7944 MB, 7944011776 bytes
255 heads, 63 sectors/track, 965 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 * 1 9 72261 c Win95 FAT32 (LBA)
/dev/block/mmcblk0p2 10 18 72292+ c Win95 FAT32 (LBA)
/dev/block/mmcblk0p3 19 56 305235 83 Linux
/dev/block/mmcblk0p4 57 965 7301542+ 5 Extended
/dev/block/mmcblk0p5 57 114 465853+ 83 Linux
/dev/block/mmcblk0p6 115 236 979933+ 83 Linux
/dev/block/mmcblk0p7 237 281 361431 83 Linux
/dev/block/mmcblk0p8 282 965 5494198+ c Win95 FAT32 (LBA)
just in case any of that helps.
i have heard of partition two being /dev/block/mmcblk0p2 but that is not a directory, or at least it appears so to me and i cannot get any files from it. I recall when the nook was booting fine i did look into the rom folder and the serial number was there and was correct, but in the settings/about Tablet it was simply a string of zeros.
when i try to pull the rombackup.zip from p3, i get the error message "adb pull /dev/block/mmcblk0p3/rombackup.zip
remote object '/dev/block/mmcblk0p3/rombackup.zip' does not exist" , so i am assuming i am barking up the wrong tree there.
when i flashed the repair zip there were no error messages and i am fairly certain it completed successfully as i was not alarmed and simply tried to reboot it as normal. after I flashed the repair zip it would not boot into anything but recovery, and this is when the more serious issue ( it seems to me) arose.
I probably am simply doing something wrong here, still the same situation on my end.
you have to mount the partitions...
rom should have been automatically mounted to /dev/block/mmcblk0p2 but you can try to manually do it:
adb shell busybox mount /dev/block/mmcblk0p2 /rom
adb shell mkdir /backup
adb shell busybox mount /dev/block/mmcblk0p3 /backup
adb pull /backup/rombackup.zip
unzip rombackup to a folder..
push the files to /rom/devconf
DizzyDen -
Thank you for telling me about the partition mounting. this explains a lot.
i had to create the /rom folder as it was not there. when i mounted it and did an ls -a command, in /rom there was only a BCB file. in /backup there was only factory.zip and an empty folder called lost+found. so there was no rombackup.zip for me to pull and extract.
sert57 said:
DizzyDen -
Thank you for telling me about the partition mounting. this explains a lot.
i had to create the /rom folder as it was not there. when i mounted it and did an ls -a command, in /rom there was only a BCB file. in /backup there was only factory.zip and an empty folder called lost+found. so there was no rombackup.zip for me to pull and extract.
Click to expand...
Click to collapse
That probably is why my repair failed. Try creating the SerialNumber file I mentioned in my last post and put it in the folder devconf. You may have to make that directory first. Mkdir /rom/devconf.
leapinlar said:
That probably is why my repair failed. Try creating the SerialNumber file I mentioned in my last post and put it in the folder devconf. You may have to make that directory first. Mkdir /rom/devconf.
Click to expand...
Click to collapse
I successfully created the file SerialNumber and it was 17 bytes, i moved it to /rom/devconf and looked at its permissions, and for some reason a chmod wouldn't let me remove rwx from others and x from user and group, so the permissions were rwxrwxrwx (not sure if this would create an issue). i tried to re-install the repair zip. the text displayed is
(after finding, opening, and installing update)
Repair /rom partition (P2)
found /factory - be patient this could take a while
Done.
This is the same message i received earlier when i did this. so no failure message but i guess it aborted or something. After this is done the devconf folder is gone. rom is still there and i mount it, and once mounted the only file in Rom is the BCB file.
I did some testing and the SerialNumber file by itself is not enough to get it going. There are 16 others and one or more may be critical. I will keep playing and see if I can find which one it needs. I don't know why you don't have that backup file. It is really critical. I modified my partition 2 zip to give a little more information to the user.
Edit: I did some more testing and it booted only to recovery when I removed a file named BootCnt. It is a file with four bytes in it which are all null (00's). Try making one and pushing it to /rom/devconf and see if it will boot. There is also another file named BootCount also with four null characters, but it is still there and it is not booting to the rom. I think that is the one for 8 failed boots. (When I rebooted again it was ok, that file was back).
Edit2: I think I found it. There is a file named DeviceID that is identical to the SerialNumber file. When I delete that file it will no longer boot to a rom, only recovery. Try putting that file in /rom/devconf. I deleted everything in that folder but BootCnt and DeviceID and it booted to the rom.
Thank you so much!! The nook is finally able to boot successfully to a ROM. Major problem finished! I was originally intending to return it to stock, but I am not sure if that is now possible as I am missing all but 2 of the very important files. I'll give an update when I get closer to getting stock back. Hopefully it will work, but we will see. Thanks for helping me get at least this far.
I have a CWM flashable 1.4.3 stock zip here:
http://d01.megashares.com/index.php?d01=CiYdDmP
sert57 said:
Thank you so much!! The nook is finally able to boot successfully to a ROM. Major problem finished! I was originally intending to return it to stock, but I am not sure if that is now possible as I am missing all but 2 of the very important files. I'll give an update when I get closer to getting stock back. Hopefully it will work, but we will see. Thanks for helping me get at least this far.
Click to expand...
Click to collapse
I .have a complete recovery.zip file available when I get my PC monitor working again... complete with infllo about what files are edited... and how to edit them
I think they are in my deposit files share
That would be spectacular if you could provide that. I'm still attempting leapinlars download ( 3 failed times, WiFi here is VERY slow right now). Let you know what happens.
So I installed 1.4.3 to the nook. it got stuck at the silver n screen, so i did a volume up, power, and n button reset. after this it reset to factory and intalled an update. it booted sucessfully to the stock firmware. now when i try to register it it is missing the model number and mac address. im assuming i am just supposed to create the two files for the nook and place them in /rom/devconf. Could some more assistance be had for me about what goes into the files and such? Mac address has been missing since the problem began, so that is nothing new, but this is the first time ive booted to stock that model number was not there.
Model number is BNRV200 in ModelNumber. Product ID begins with P11 and ends with a linefeed and is 11 bytes total in ProductID. Event Type is Manufactured in EventType. Date manufactured is just a date. Mine was 01/29/2011 in DateManufactured. Device attribute is New in DeviceAttribute for me. MAC address is a 12 digit number in hex in MACAddress. Main board serial number is a 12 digit alphanumeric number in MainboardSN. Mine starts with QI11M. Backlight is a 6 digit alphanumeric number in backlight. Mine is 1476AY. Ean is a 13 digit number in ean. Mine starts with 97814005. There is an empty Platform file. There is BootCnt and BootCount, both with four nulls (00). There is a SerialNumber file identical to DeviceID. There are three other files. WiFiBackupCalibration with 468 bytes, PublicKey with 333 bytes and HashOfPrivateKey with 28 bytes.
Some of these you can make and some you can put phony info in them. Others, I don't know.
Could you provide more info on obtaining the Mac address and how to write it? After that I should be good, but we will see.
[edit]
install cm7.2 and it was in the settings, so i copied it down and put it on the device. reverting back to stock, i will see if it takes. i am assuming by your description the semicolons are not placed in the MACAddress file, so i did not do it.
[edit2]
looks like all i need is the hashprivatekey. when i went to the factory area a few were null, but that one said Not Okay. is there any way i can create this file? i tried registering but it would not, so i am assuming this is needed.
Unblock your private messaging on XDA. I want to send you a message. Or send me a private message with your email address in it.
Sent from my NookColor using Tapatalk
ok. it boots fine. when i register it will not let me, with the typical error, i look into the details and everything is green except battery percentage (which is low) and username which is nonexistant. when i check the factory tab it says that the battery type and backlight are !null, so i dont thing that would affect it. besides that i have everything.
One more thing to try. You can reset some of your settings like wifi calibration, etc by following this procedure. It may just re-populate some of those files in devconf. Use the one that resets things. Back up devconf first though.
http://nookdevs.com/NookColor_Factory_Mode/Skip_Out_of_Box_Experience
done that a few times. it doesnt really do anything but erase known wifi networks. would the fact its missing battery type and backlight mean anything for registration?
I would not think so. But I have a Nook Tablet that has different things in devconf, like BatteryType is MCNAIR and Backlight is 070B16730338ZN4AC15-4J8D6Y01577C5. (Notice it has a capital B in the name. I think I made a mistake in the earlier post.) The Tablet I think has the same screen as the newer Nook Colors.
Greetings,
I'm new to these forums, but have been into the Android development/customization scene since the original Motorola Droid. I recently purchased one of the (in)famous Chinese 8227L head units and have started doing some things to it. I was surprised to find that there are a lot more people out there with questions than answers when it comes to these things. So I figured I'd introduce myself with a quick tutorial, a small utility release for now. I have work in progress on a ROM release for these things. There are quite a few issues to get past as well as different boards to account for, so stay tuned for that sometime in the coming weeks. For now, let's get started with customizing the boot screen.
One of the simplest, yet most satisfying modifications one can do to any Android device is changing logo image that is displayed when the unit boots. For units like ours, running MediaTek hardware there are a couple of extra steps involved, but the process is still very simple. I was able to find a few different utilities that could be downloaded online to do this, but none of them seemed to work for these head units. I suspect our units use a slightly different header than the MediaTek phones those utilities are designed for, but that is a technical issue beyond the scope of this tutorial.
Disclaimer: These steps have been tested repeatedly on my device, and it's my assumption that they will work on any head unit based on the ac8227l, but I have obviously not tested every single one of them. There is always an inherent risk when you modify the software on any device that you own. This risk is your own, and I am not responsible for any damage you do to your device by following this tutorial!
Your unit does not need to be rooted to do this mod, but you will need to have the bootloader unlocked.
Pre-requisites:
logo.bin file from your ROM backup (You DO have a backup, don't you?)
Ability to read and follow directions
Access to a Linux command line OR the ability to run python applications on your system
SP Flash Tool or one of its equivalents, or a custom recovery installed, such as TWRP.
The boot logo is contained in the logo.bin file from your ROM. More accurately, the logo.bin file IS the boot logo for your ROM, with a 512 byte header attached to it. We need to separate the two in order to change the image that gets displayed.
This can be done very simply from the linux command line via the following command:
Code:
dd if=logo.bin of=logo.bmp skip=1
This command simply reads in the logo.bin file and writes it back out after skipping the first 512 bytes. dd has an optional argument bs= which stands for block size. It defaults to 512 bytes. So the skip=1 is simply
telling dd to skip the first 512 bytes when it writes the file back out. The result is a 1024x600 pixel bitmap image. However, we're going to need that header in a later step, so write it out to its own file using:
Code:
dd if=logo.bin of=header.bin count=1
This command simply writes the first block (remember block size is 512 bytes by default) out to a file and then stops, so we have our 512 byte header saved for later.
Now, you can either edit the logo.bmp file or replace it with your own image file. However you do it, just ensure that you end up with a 1024x600 pixel bitmap image in 8-bit RGB color. The following steps assume we have generated such an image in the same directory we were just working in, and named it newlogo.bmp. To join the header file to your new image, use the following command:
Code:
cat header.bin newlogo.bmp > newlogo.bin
This command concatenates (puts together) the two files back into one file. The order is important. The header needs to be at the start of the resulting file, so it must be the first argument you pass to cat! The resulting newlogo.bin is ready to be flashed to your head unit. Congratulations, enjoy your new boot screen! If you save the header.bin file, you can always use it to make more boot logos later.
Alternative method for Windows users or Linux users who would prefer to have a utility:
I have written a simple command line utility in python to do this process for you. You will need to have python installed to utilize it. It's written in python 3.8 but will work on some earlier versions, I think. You can get it from my github repository at https://github.com/threadreaper/logobin.git or from your command prompt using the PyPi repository through pip3. pip3 should be installed automatically when you install python 3. Use this command to fetch the utility:
Code:
pip3 install logobin
If you've elected to clone the git repository instead of using PyPi, you need to cd to the directory you downloaded it to (this should be the directory with the setup.py file) and install using:
Code:
pip3 install .
Whichever method you used, if everything went correctly, the "logobin" utility should now be available to you from your command line. To unpack an existing logo.bin image:
Code:
logobin -u logo.bin
And to pack an image with a header file back into a flashable bin file:
Code:
logobin -p header.bin logo.bmp (filename)
The filename argument above is optional and defaults to logo.bin if you don't select one. The utility can also be used to check a file for the presence of a valid header, using the -c switch:
Code:
logobin -c logo.bin
In this manner, you can check your stock logo.bin file to make sure it will work with this method before you start. You can also use it to check an extracted header to make sure it's correct, and you may also want to use it to verify that your logo.bin file has been packed correctly before you flash it to your phone.
I have attempted to make both the utility and this tutorial as simple to follow as possible, but if you have any questions, feel free to ask.
Excellent tutorial? I have a non rooted Enon 8227 unit and I’m having problem with it, could you be so kind to point me to a tutorial to make a rom backup please? all the stuff in my unit are blocked and I can t almost change anything.
Thank you.
Sent from my iPhone using Tapatalk Pro
Good day sir.
Could you guide me as to how to extract the logo.bin file please? I couldn't really find it.
I have a PX6 STM32 device.
Thanks!
arturojgt said:
Excellent tutorial? I have a non rooted Enon 8227 unit and I’m having problem with it, could you be so kind to point me to a tutorial to make a rom backup please? all the stuff in my unit are blocked and I can t almost change anything.
Thank you.
Sent from my iPhone using Tapatalk Pro
Click to expand...
Click to collapse
I'm planning to do a full tutorial on this too, but the short version is as follows:
Get SP Flashtool, and find a scatter file that will work for your device. That can be difficult sometimes, as there is a quite a bit of variance between units. Fortunately, to make your initial backup the only info you need in your scatter file is for the preloader, and as far as I know that is always the same. So if you don't already have a scatter file copy this:
Code:
#########################################__WwR_MTK_2.50__###################################################
#
# General Setting
#
#########################################__WwR_MTK_2.50__###################################################
- general: MTK_PLATFORM_CFG
info:
- config_version: V1.1.2
platform: MT3367
project: 8227l_demo
storage: EMMC
boot_channel: MSDC_0
block_size: 0x20000
############################################################################################################
#
# Layout Setting
#
############################################################################################################
- partition_index: SYS0
partition_name: preloader
file_name: preloader_8227l_demo.bin
is_download: true
type: SV5_BL_BIN
linear_start_addr: 0x0
physical_start_addr: 0x0
partition_size: 0x40000
region: EMMC_BOOT_1
storage: HW_STORAGE_EMMC
boundary_check: true
is_reserved: false
operation_type: BOOTLOADERS
is_upgradable: true
empty_boot_needed: false
reserve: 0x00
And save it as scatter.txt
Select this file as your scatter file in SP Flashtool, and click on the memory test tab. Uncheck all the options under memory test except for RAM test. Remove external power from the unit entirely, click start on the memory test, and then connect the 4 pin usb to your PC. It should sync up and do the memory test. Once the memory test is complete you will have the sizes of BOOT_1, BOOT_2 and EMMC_USER. Use these values with the readback option to make your backup. Use 0x0 as the start address each time, and the size value you got from the memory test. Back up BOOT_1, BOOT_2 and EMMC_USER and save them somewhere. This is the most basic backup that you can always use to go back to stock. Using tools like MTK Droid Tools and WWR MTK it is possible to split EMMC_USER backup into all of your separate partition backups.
Good luck, and keep an eye out for a more detailed walkthrough coming up soon!
kingdew11 said:
Good day sir.
Could you guide me as to how to extract the logo.bin file please? I couldn't really find it.
I have a PX6 STM32 device.
Thanks!
Click to expand...
Click to collapse
See my reply above about making a backup of your device. You get your logo.bin file from the extracted backup.
Please add your PayPal account to your xda so we can buy you some beer for the amazing work you're doing
Sent from my MI 9 using Tapatalk
zetlaw01 said:
Please add your PayPal account to your xda so we can buy you some beer for the amazing work you're doing
Sent from my MI 9 using Tapatalk
Click to expand...
Click to collapse
I don't drink beer, but you can always buy me a coffee
Thanks for information.
I want to backup with Flastool or similar program, is that possible?
and how do I root.
thank you
bicer79 said:
Thanks for information.
I want to backup with Flastool or similar program, is that possible?
and how do I root.
thank you
Click to expand...
Click to collapse
I posted instructions on backing up a unit two posts above your reply ^^. To root, find a compatible twrp image and flash it, then install magisk from twrp. I will be doing more detailed tutorials on these steps in the near future, but as I mentioned there is a crash course on SP-flashtool backup in this very thread, and the root process is pretty much the same for these units as it is for many others, assuming you find a working twrp image for your particular device, so you shouldn't have too much trouble finding a walkthrough if you need one.
threadreaper said:
Greetings,
I'm new to these forums, but have been into the Android development/customization scene since the original Motorola Droid. I recently purchased one of the (in)famous Chinese 8227L head units and have started doing some things to it. I was surprised to find that there are a lot more people out there with questions than answers when it comes to these things. So I figured I'd introduce myself with a quick tutorial, a small utility release for now. I have work in progress on a ROM release for these things. There are quite a few issues to get past as well as different boards to account for, so stay tuned for that sometime in the coming weeks. For now, let's get started with customizing the boot screen.
One of the simplest, yet most satisfying modifications one can do to any Android device is changing logo image that is displayed when the unit boots. For units like ours, running MediaTek hardware there are a couple of extra steps involved, but the process is still very simple. I was able to find a few different utilities that could be downloaded online to do this, but none of them seemed to work for these head units. I suspect our units use a slightly different header than the MediaTek phones those utilities are designed for, but that is a technical issue beyond the scope of this tutorial.
Disclaimer: These steps have been tested repeatedly on my device, and it's my assumption that they will work on any head unit based on the ac8227l, but I have obviously not tested every single one of them. There is always an inherent risk when you modify the software on any device that you own. This risk is your own, and I am not responsible for any damage you do to your device by following this tutorial!
Your unit does not need to be rooted to do this mod, but you will need to have the bootloader unlocked.
Pre-requisites:
logo.bin file from your ROM backup (You DO have a backup, don't you?)
Ability to read and follow directions
Access to a Linux command line OR the ability to run python applications on your system
SP Flash Tool or one of its equivalents, or a custom recovery installed, such as TWRP.
The boot logo is contained in the logo.bin file from your ROM. More accurately, the logo.bin file IS the boot logo for your ROM, with a 512 byte header attached to it. We need to separate the two in order to change the image that gets displayed.
This can be done very simply from the linux command line via the following command:
Code:
dd if=logo.bin of=logo.bmp skip=1
This command simply reads in the logo.bin file and writes it back out after skipping the first 512 bytes. dd has an optional argument bs= which stands for block size. It defaults to 512 bytes. So the skip=1 is simply
telling dd to skip the first 512 bytes when it writes the file back out. The result is a 1024x600 pixel bitmap image. However, we're going to need that header in a later step, so write it out to its own file using:
Code:
dd if=logo.bin of=header.bin count=1
This command simply writes the first block (remember block size is 512 bytes by default) out to a file and then stops, so we have our 512 byte header saved for later.
Now, you can either edit the logo.bmp file or replace it with your own image file. However you do it, just ensure that you end up with a 1024x600 pixel bitmap image in 8-bit RGB color. The following steps assume we have generated such an image in the same directory we were just working in, and named it newlogo.bmp. To join the header file to your new image, use the following command:
Code:
cat header.bin newlogo.bmp > newlogo.bin
This command concatenates (puts together) the two files back into one file. The order is important. The header needs to be at the start of the resulting file, so it must be the first argument you pass to cat! The resulting newlogo.bin is ready to be flashed to your head unit. Congratulations, enjoy your new boot screen! If you save the header.bin file, you can always use it to make more boot logos later.
Alternative method for Windows users or Linux users who would prefer to have a utility:
I have written a simple command line utility in python to do this process for you. You will need to have python installed to utilize it. It's written in python 3.8 but will work on some earlier versions, I think. You can get it from my github repository at or from your command prompt using the PyPi repository through pip3. pip3 should be installed automatically when you install python 3. Use this command to fetch the utility:
Code:
pip3 install logobin
If you've elected to clone the git repository instead of using PyPi, you need to cd to the directory you downloaded it to (this should be the directory with the setup.py file) and install using:
Code:
pip3 install .
Whichever method you used, if everything went correctly, the "logobin" utility should now be available to you from your command line. To unpack an existing logo.bin image:
Code:
logobin -u logo.bin
And to pack an image with a header file back into a flashable bin file:
Code:
logobin -p header.bin logo.bmp (filename)
The filename argument above is optional and defaults to logo.bin if you don't select one. The utility can also be used to check a file for the presence of a valid header, using the -c switch:
Code:
logobin -c logo.bin
In this manner, you can check your stock logo.bin file to make sure it will work with this method before you start. You can also use it to check an extracted header to make sure it's correct, and you may also want to use it to verify that your logo.bin file has been packed correctly before you flash it to your phone.
I have attempted to make both the utility and this tutorial as simple to follow as possible, but if you have any questions, feel free to ask.
Click to expand...
Click to collapse
did you build twrp from source or port it for your device?
I was able to build TWRP from source, but I haven't released it due to some rather annoying bugs I haven't had time to sort out with it just yet.
threadreaper said:
I was able to build TWRP from source, but I haven't released it due to some rather annoying bugs I haven't had time to sort out with it just yet.
Click to expand...
Click to collapse
which bugs?
I am so delighted to see someone hitting on the hot iron. Looking forward to the detailed tutorial to take backup, unlock bootloader, customize my radio.