So, I've been reading a bit about how to install 2.2 on my g1. My initial impressions as a first time rooter is that it is a bit complicated. I really would like to know what I'm doing in case anything goes wrong. However, I've been a bit frustrated by any of the information I've found on google about it. Most of the tutorials only tell you what to do without explaining why you are doing it. Any explanations about how things works have been pretty brief and not much goes into how each piece of the android system relates to the other.
I'm going to run through my trouble points with learning it and if someone could jump in and explain any one of these things it would help me out a lot and hopefully other people as well.
There are (at least?) 4 main parts you need to be concerned with when installing a custom rom:
-the custom rom itself
I'm not totally sure of everything that goes into this. All the java stuff I'm guessing. Dalvik vm? Maybe the linux kernel? Some c libs too? busybox? Some other stuff?
-the spl.. aka second program loader.. I found the following explanation for this one:
Second Program Loader, in conjunction with the IPL comprise a device's bootloader. Aside from bootstrapping Android, the bootloader also fulfills various diagnostic functions. One of these functions is the manipulation of data in the device's internal flash ram. Depending on the SPL installed, the user can apply a signed NBH file, flash nand images, and more. Note that the SPL is installed and operates independently of the Android build that runs atop it. (Hold down the Camera button while the phone is booting to enter the SPL.)
Click to expand...
Click to collapse
Seems fairly straightforward. How does the IPL factor into this though? Why is the IPL typically not a concern when installing roms? What is a nbh? How does a nbh relate to a .img? Why does this get flashed?
-the radio.. i have no idea what this one is for.. references to it typically seem to be vague and mysteriousi have heard it is quote "the easiest way to brick your phone" which leads me to believe it is important. Appearantly danger SPL will kill you if you dare mess with it. This scares me because I dont really even know what it is so how am i supposed to know if I'm messing with it?
I have heard this description:
"radio.img is a image of partition table + several partitions, which are defined in the header.
You can open the file in hex editor and see it (starting at 0x18 offset):
MAGIC-NOTHING2DO: does nothing
OTA-QCSBL-UPDATE: updates qcsblhd_cfgdata.mbn and qcsblsec.mbn
OTA-OMSBL-UPDATE: updates oemsblhd.mbn and oemsblsec.mbn
OTA-RADIO-UPDATE: updates amsshd.mbn and amsssec.mbn (the actual baseband firmware)
OTA-APSBL-UPDATE: updates appsboothd.mbn and appsbootsec.mbn
OTA-CEFS--UPDATE: updates cefs.mbn (on some radio.img files this is done implicitly)"
Click to expand...
Click to collapse
What is this talking about? How do the partitions relate to what goes on when you are installing a rom? What is it used for? Why are there so many versions of it? Why?!
Finally:
-the recovery.img - this one is also a shroud of mystery to me. I'm not sure how it relates to the spl and it seems like sometimes you use this to install updates and sometimes you use the spl. I'm just not really sure how this factors into things.
This also seems to be involved a lot in things like 'repairing ext file systems' etc. What ext file system is it repairing? The sd card? The internal storage? Why are you supposed to repair it?
I have more questions but I will leave it at this. Thoughts anyone?
Hi All.
It's my thread - port Android on Wave S8500(also S8530).
Wellcome developers and designers.
Last state of project:
06/13/2011 Now working on Android 2.3.3 (Source GB for GT-I9000 and M130K)
not working - modem and GPS.
04/04/2011 Memory allocation now is correct!
05/11/2011 I have full schematic for phone
and we're ready to get a fully working kernel.
Full decriptions of GPIO is attached.
source for kernel and initramfs here:
github.com/Oleg-k/S8500_Kernel_2.6.32
github.com/Oleg-k/initramfs_2.6.32_S8500
(real shame if you ask me)
Click to expand...
Click to collapse
Please expect not too much from me.
1.
My other handsets are from 2006... NEVER hold Android handset in my own Hand...
2.
I'm Windows User.
Linux/Unix ... I know only 1 or 2 Commands
I've never formated my SD Card nor any Harddrive with Linux ext4, JFS, ReiserFS or XFS
3.
I NEVER worked with IDA or something similar.
Installed yes, but then my Head exploded
Brain too small.
4.
Many missing parts...
Why I should kill my alive handset, as I have no real chance to reanimate it...
- no Riff Box
- no PCB to play with
I AM NOT the right man to port Android nor to find Security hole
You can make this post sticky.
NO joke, expect not too much from me. We can learn together... but this takes time.
Many time. Months, maybe years...
Best Regards
after many many variant, i found the right boot+sbl+param.lsf for kernel message output.
this is my last bootlogo.
how it can be seen, there is a problem with memory allocation.
oleg_k said:
after many many variant, i found the right boot+sbl+param.lsf for kernel message output.
this is my last bootlogo.
how it can be seen, there is a problem with memory allocation.
Click to expand...
Click to collapse
Great of you to keep us posted! \o/
hmmm... as a matter of interest - I noticed you're using kernel 2.6.35.7, when I look at the original I9000 source that's 2.6.29....
what does that source say as to why it failed in bootmem.c @ line 341?
Not enough memory, permissions, wrong offset?
oleg_k said:
not yet( Starting but don't finish.
Click to expand...
Click to collapse
Whats not happening? Oleg_k would you be able to PM me with a copy of your work, files and so forth i might be able to help you out.
t0mm13b said:
+1 for bootloaders - abso-frickin-lutely....there should be a standard bootloader... meh.... not sure about meteor - haven't seen it...
Click to expand...
Click to collapse
Well I'm holding a meteor wave here, bought around christmas. How much onboard storage does you device have? mine says it only has 512 i think... stupid meteor thinking i wouldn't notice....
sabianadmin said:
Well I'm holding a meteor wave here, bought around christmas. How much onboard storage does you device have? mine says it only has 512 i think... stupid meteor thinking i wouldn't notice....
Click to expand...
Click to collapse
You mean to tell me that Meteor bundled a 512Mb memory card?
I have 4Gb on mine...this memory thing is a bit mystifying dontcha think, despite the discussion on another thread about the nand chipset.... on the one hand some say its 256Mb, others say 512Mb...
I tried the versions 2.6.32 and 2.6.35.
I post sbl+boot+param.lfs and config file for kernel making.
Last time u had problem with lcd_rst pin..did u figure that out?
t0mm13b said:
You mean to tell me that Meteor bundled a 512Mb memory card?
I have 4Gb on mine...this memory thing is a bit mystifying dontcha think, despite the discussion on another thread about the nand chipset.... on the one hand some say its 256Mb, others say 512Mb...
Click to expand...
Click to collapse
No i mean Meteor gave me some (seeminly non existant) version of the wave that has 512 internal storage. Im pretty sure its meant to have 2-4gb at the minimum.
sabianadmin said:
No i mean Meteor gave me some (seeminly non existant) version of the wave that has 512 internal storage. Im pretty sure its meant to have 2-4gb at the minimum.
Click to expand...
Click to collapse
Wave have 2gb of internal storage, but only 512mb are free for the user.
Otacon_ahs said:
Wave have 2gb of internal storage, but only 512mb are free for the user.
Click to expand...
Click to collapse
Wave S8500 have 2Gb of internal storage which are partitioned (bada 1.0.2):
-about 512Mb for messages (mail+sms);
-about 420Mb for user files;
-about 1Gb for system files (os+apps+widget+java)
You can find it in: Setting-->Memory-->Memory Status-->Common Memory
@ oleg_k
1.
How to bypass to write/overwrite Boot without JTAG?
I stuck in problems with Multiloader to write decrypted unmodified Original Boot. See here:
http://forum.xda-developers.com/showpost.php?p=12607344&postcount=34
2.
How to build valid Bootimage for JTAG or file(s) to use your uploaded files.
Maybe you could please upload your working Bootimage from S8500?
So we had something to start with...
3.
You have working fallback/recovery plan? To get back to working bada S8500.
Or only JTAG...
4.
Anyway. Thanx for uploading files for study.
Best Regards
To adfree,
1)now the steps bada->android or android->bada is only via JTAG.
i'm don't know any other way.
2)i posted full working bootloader files in first message of my thread.
3)i will post full jtag image with semi-working android in 2 hours.
Regards
my friend
Thank you oleg_k
Last Question for today.
So I should use simple Flashtool from I9000 to flash these Boot Files into S8500 ?
Sorry for stupid Question. But I'm totally Android Noob.
Thank you for uploading files.
Best Regards
oleg_k said:
To adfree,
1)now the steps bada->android or android->bada is only via JTAG.
i'm don't know any other way.
2)i posted full working bootloader files in first message of my thread.
3)i will post full jtag image with semi-working android in 2 hours.
Regards
my friend
Click to expand...
Click to collapse
We can think about running SBL or any other bootloader (anybody with sources for that?) through the FOTA hole as I described in the thread:
http://forum.xda-developers.com/showthread.php?t=1020444
This way we don't need JTAG for initial flashing. It'd be also good to perform testing without touching BADA in the NAND, but we either need to reorganize partitions or boot from SD card
Best Regards,
mijoma
I think an combination will lead to success... so work together.
At this status it is maybe tooo risky to play without JTAG.
As we not know, how Android will handle Memory...
Okay, correction. I don't know.
In worst case scenario you need JTAG to reanimate Wave...
We have 2 steps/parts.
Android part.
Display, Kernel, Memory, etc...
This part is mandatory in my opinion.
Then second part, how to start Android. Then there are several theories...
BootLoader, No BootLoader, FOTA... inject via JTAG into RAM...
internal Memory or Dual Boot from SD Card...
Anyway, without proper modified Android part we can't use all our Security Holes.
As more infos we have, better, as more working solution we have.
So more chance to improve something.
At the moment we can only improve Video Quality.
Best Regards
Mijoma,
I totally agree with you,maybe this is the way to deploying android on S8500.
But now,i think about build working kernel for our s8500.
Maybe you helping with analize memory init on original bootloader?
like this - http://code.google.com/p/jetdroid/wiki/OriginalDramInit
Regards
Seems like using mijoma's discovery you should be able to replace booting and maybe make it to boot from SD card using a open source booter a compatible android kernel with selfmade drivers.
Maybe that could be the way, sadly we'd lose internal storage since we wouldn't be touching bada partition, anyway Android should be working fine from a SD card, It does properly on other handsets which internal storage is nothing more than a microSD card instead of flash memory.
I think losing 2GB on internal and XMB on microSD is a good deal for having android on our handsets. Happily I got 16GB SD on my wave xP. Anyway once you achieved that we could gather to use the internal flash memory partition
Jioma I suggest you to work with adfree (along your knowledge) and oleg_k they're our wave masters, baybe you together could gather to achieve this great project. I require you to work on this oh please jioma=(
Ok thats great news! Finally we have a method of booting other platforms on the Wave. What we need is as much information on the s5800 chipset as we can get so we know exactly what to compile and what drivers are needed in the linux kernel for android. Someone get in touch with Cyanogen mod and ask him for help and offer him a wave or something ha.
I've been playing with the new firmware file for a few hours now, but can't really extract it. I'm really interested in the apps, etc, so could someone tell me if there's any way to extract it? OpenAOS, and other archos AOS extractors didn't work sadly.
If someone could do me a system dump of the 101 G9, it would make this whole extraction unneeded (for me atleast!).
Thanks in advance!
And what do you want to do?
None of the Apps will work as they are for HoneyComp.
They all need a newer OS and all the other things that come with the new tablet.
It would be the same useless try that has been done in the beginning of the year with the HC SDK Binaries.
Stop hurting yourself and wait for ICS Sourcecode and then we will see.
fzelle said:
And what do you want to do?
None of the Apps will work as they are for HoneyComp.
They all need a newer OS and all the other things that come with the new tablet.
It would be the same useless try that has been done in the beginning of the year with the HC SDK Binaries.
Stop hurting yourself and wait for ICS Sourcecode and then we will see.
Click to expand...
Click to collapse
So my Asus Transformer isn't HC? Good to know...
I exactly know what I want to do with the apps, so please, no more non helping posts. I started this thread to find answers, not stupid people commenting on everything without reading.
And where did you state that you want to use them on a Transformer?
Even then, none of the Archos APK will work there, as Archos has also changed some underlying OS Funktions and drivers.
As the Gen9 has a completely different SOC ( Tegra2 vs TI OMAP 4430/4460) none of those needed Drivers are working.
So again, what do you want?
fonix232 said:
I exactly know what I want to do with the apps, so please, no more non helping posts. I started this thread to find answers, not stupid people commenting on everything without reading.
Click to expand...
Click to collapse
To simply answer your question...
I'm not familiar with the gen9 devices, but i assume that archos did not change their basic infrastructure on these devices (using squashfs).
If that's the case there are basically three ways i'm aware of:
1. Gain root access on your device and directly copy the files to an external device. Of course this is not very comfortable and you'll have to take care of symlink's, etc.
2. Make a dump of the partition where androidmerged.squashfs.secure is
included using a dd tool or similar.
After doing so, you'll have to investigate the raw data for squashfs signature and remove the leading header.
Then you might be able to get the raw squashfs file containing all data.
This file could be mounted as loop on a linux machine supporting squashfs files.
As i pointed out, i'm not aware of the internal structure in gen9 devices, so i can't tell you which partition is the right one.
Maybe you could post some output of your device (e.g. cat /proc/partitions or mount)
Anyway i guess you'll have to be root to access the mtd devices in the end.
3. Extract the androidmerged.squashfs.secure file directly from the .aos.
Using this way you'll neet to tweak aos-tools with the correct key for gen9 devices. This key has not been published yet and that's why aos-tools is lacking support for gen9 devices.
To be honest we don't know anything about the security mechanism on gen9 yet.
Some words in common...
Please respect the rules!
Abusing other users is a no go
Regards,
scholbert
fzelle said:
And where did you state that you want to use them on a Transformer?
Even then, none of the Archos APK will work there, as Archos has also changed some underlying OS Funktions and drivers.
As the Gen9 has a completely different SOC ( Tegra2 vs TI OMAP 4430/4460) none of those needed Drivers are working.
So again, what do you want?
Click to expand...
Click to collapse
Please, do check my signature...
I want to check out the apps what aren't stock, etc.
wait the SDE
Hey fonix232,
did you see this:
http://forum.xda-developers.com/showthread.php?t=1349184
With the gen9 keys, the aos-tools could be tweaked to extract gen9 firmware files.
Ask letama for help/code.
He already successfully extracted the firmware!
Regards,
scholbert
Hi there,
Here it is:
extracted 3.6.29 firmware
Almost untouched, just with su+SuperUser.apk added.
LeTama
My question is if purchasing a used Android device could have potential security & privacy implications? I would like to start experimenting with different ROMs. I have never installed a different ROM before but I have used Fedora Linux for years and that is the basis for my question. For example, when I have purchased a used laptop off Craigslist, I would always reinstall the BIOS before putting a fresh copy of Fedora onto the laptop. Although the chance of a BIOS virus is rare, better safe than sorry.
When I was looking at a few on-line tutorials about heimdall it looks like there are a number of files that can be used in flashing a new ROM to a device; some articles talked about some of the other fields like:
- Primary Bootloader
- Secondary Bootloader
Are these bootloader files analogous to a GRUB or LILO that I would use on my Fedora Linux boxes? Or are they the same or different than the role of the hardware BIOS on a traditional x86 motherboard? Are there other files that fulfill other similar functions?
It seems like the bootloader files are exclusive for the specific device that they are on. So I am betting that installing the wrong primary or secondary bootloader onto a device could well brick it. Kind of like installing the wrong BIOS update on an x86 motherboard would likely turn it into a piece of toast as well.
Much like BIOS virus are equally as unique to the motherboard as they are rare, they unfortunately still exist.
My question is if it is possible to buy used device that is infected and not have a way to "re-install the BIOS" for lack of better wording. If that were the case then potentially any MOD that I were to put on to the device would still lend it to being compromised in a similar way to a rootkit virus?
I am a complete Android noob so I apologize if these problems don't exist in the mobile space or are already solved. My only frame of reference is the traditional x86 experience and I can't seem to locate anything online
Thanks everybody! :cyclops:
Hello,
some discussions on android-hilfe.de about the Honor 7 modem partition and additionally Wanams App "Partitions Backup & Restore" brought me to the following issue:
The Honor 7 has a bunch of partitions and some partitions seem to be very device specific.
Looking into Wanams App (s. attachments) several partitions are marked with a yellow background as "IMEI / EFS related". Because of that I am assuming that device specific informations like IMEI, serial nummber, mac addresses for WLAN and Bluetooth etc. are stored on one or more of those special partitions (I think that the time to burn such informations on EPROMs is gone, isn't it?).
That's leading to my question: Can somebody tell me which device specific information is stored on what partition?
I think that this aspect is very important for those who want to create their own Custom ROM because it would be very "stupid" if you provide a ROM that changes one of those partitions and later on you have to recognize that all affected devices have (for example) the same IMEI.
Thank you in advance and best regards
m_esser
Curious ... this forum has thousands of users and has a community with an extremely high knowledge level ... but nobody can answer my questions?
I'm not a developer, but I've tried to REPIT my partitaions to get more space on phone.
Hope this post below helps:
https://github.com/Lanchon/REPIT/issues/28
jerryhou85 said:
I'm not a developer, but I've tried to REPIT my partitaions to get more space on phone.
Hope this post below helps:
https://github.com/Lanchon/REPIT/issues/28
Click to expand...
Click to collapse
Thank you very much for the above mentioned link ... very intersting but unfortunately I didn't find what I am searching for. The thread you mentioned is more focussed on partition sizes etc and not on the content (what is stored where on the very Huawei specific partitions? ).
Best regards
m_esser
That's worth something searching for.
But isn't the IMEI hardcoded to the motherboard only?
I bricked my previous device, and they changed the MOBO, and upon receiving it I checked IMEI and it was changed, but the device was same, I had a dent as mark on the back.
DigiGoon said:
That's worth something searching for.
But isn't the IMEI hardcoded to the motherboard only?
Click to expand...
Click to collapse
Depending on the perspective what "hardcoded" means the answer can be Yes and No .
If there is a dedicated chip on the motherboard (like it was in the early PC days on ethernet cards) that would surprise me because this approach would be very "old fashioned" ... the days of EEPROMs are definitively gone.
Thus I am assuming that the IMEI and other informations are stored in flash memory and further I assume that the manufacturer takes one of the undescriped partitions for this purpose ... only a guess but for me very likely because additional chips or elements would only lead to higher costs.
But currently it looks like we will never know ...
Best regards
m_esser
m_esser said:
Depending on the perspective what "hardcoded" means the answer can be Yes and No .
If there is a dedicated chip on the motherboard (like it was in the early PC days on ethernet cards) that would surprise me because this approach would be very "old fashioned" ... the days of EEPROMs are definitively gone.
Thus I am assuming that the IMEI and other informations are stored in flash memory and further I assume that the manufacturer takes one of the undescriped partitions for this purpose ... only a guess but for me very likely because additional chips or elements would only lead to higher costs.
But currently it looks like we will never know ...
Best regards
m_esser
Click to expand...
Click to collapse
It may not be a chip, but a small flash storage somewhere on the board, which stores the IMEI and stuff, if not then why the IMEI changes when the motherboard changes.
Or maybe a hidden partition.
But then again, who knows.
Thanks