yashsingh1/xdaforums huggingface dataset:
[Nexus One Q&A, Help & Troubleshooting] false_chicken:
I just got a imported nexus one today. And I am following the guide to install cyanogen on it. But after I flash the recovery (Both clockwork and RA) I get just a black screen when I boot into recovery. Fastboot says it writes it successfully. And ADB says my device is in recovery. My fastboot shows this:

NEXUSONE PVT SHIP S-ON

HBOOT-0.35.0017

MICROP-0c15

TOUCH PANEL-SYNT0103

RADIO-5.08.00.04

Jun 14 2010, 12:02:27

Any suggestions? I bought the nexus for cyanogen. Would be a shame if I cant get it to work:(
[Nexus One Q&A, Help & Troubleshooting] danger-rat:
You probably have the SLCD screen.

Only Amon Ra 1.8.0.1 and 1.9 are compatible... You'll also need a compatible ROM (if you plan on changing).
[Desire Q&A, Help & Troubleshooting] leecotton:
Hello all. Just got an unbranded HTC Desire, which comes with the firmware of 2.1-update1. I've tried checking for updates but it doesn't find the 2.2 which I believe is available now. Anyone got any idea why? The software number is 1.21.405.2 if that is any help.

Thanks for any help, anyone!

Lee
[Desire Q&A, Help & Troubleshooting] AndroHero:
you need software version 1.22.61.1 before you can do the ota on orange.. but you can grab the ota from here http://androidforums.com/htc-desire/188136-orange-2-2-ota-update-download-here.html
[Desire Q&A, Help & Troubleshooting] leecotton:
Thanks for the quick reply. My SIM is Orange, but the handset is not, it's unbranded. Is it the SIM that's stopping this then? I was checking for updates via wifi, so I would have thought the SIM brand wouldn't matter?
[Desire Q&A, Help & Troubleshooting] AndroHero:
sorry i missed that on you op....you should of got the ota by know, the generic one was the first one release :confused:

*edit* if you want you can download the generic ota from here http://www.mikesouthby.co.uk/2010/08/htc-desire-official-ota-update-download-here/
[XPERIA X10 Q&A, Help & Troubleshooting] Adolf1994:
Hi

Is there any method to block or remove the stock lockscreen to replace with another, like GOTO.

Thanks in advance
[XPERIA X10 Q&A, Help & Troubleshooting] im_iceman:
Please search before you post.. there's already way too much crap on here..

Look here - http://xdaforums.com/showthread.php?t=732256&highlight=lock+screen
[Galaxy S I9000 Android Development] RyanZA:
There is very little technical information on PIT files , so this thread is an attempt to find out some real details about PIT files, and perhaps eventually be able to create our own PIT files (by modifying Samsung ones, probably).

First, what we think we know PIT files do:

- PIT files only affect the 'STL' devices. That is, it affects the OneNAND and not the MoviNAND.

- PIT files appear to control the sizing (and maybe number) of STL devices that appear in Linux.

- PIT files appear to be used by Odin to map filenames inside .tar archives to STL partitions.

STL files are quite small, at under 2KB in size. Most of the file is made up of 0s. I have tried to compare the differences between the 512 513 and 803 PIT files we have available.

All the PIT files start with 76 98 34 12 0D - probably a signature to show it is a PIT file.

[Unimportant]

The 803 PIT file then has 00s all the way to the next common point. The 512 and 513 both have common data till the next common point - but this can't be too important as the 803 just has 00s.

The next common bit seems to read the following:

"oft IBL+PBL Server\90\To boot.bin inn; C:\Program Files\ESTsof

This probably indicates something to Odin. Strange that it has C:\Program Files\ - build path for the PIT file?

Next we have some 0s with common 1s inside them, followed by the word PIT, then more 0s, and then ries.pit. All common from here on with the words 'EFS' and 'efs.rfs'. Probably telling odin to map the efs.rfs file to the 'EFS' token. Tokens probably defined either in the kernel, or in the closed source STL library. More of the same of this, with 'SBL' 'sbl.bin', 'SBL2' 'sbl.bin' -- Both SBL and SBL2 map to the same sbl.bin file?

'PARAM' to 'param.lfs'

'KERNEL' to 'zImage'

'RECOVERY' to 'zImage' (this one is interesting - could we have seperate zImage and recovery? Could save some RAM here!)

[/Unimportant]

And now we'r onto the actual changes between the PIT files. 'FACTORYFS' maps to 'factoryfs.rfs'. However, before the FACTORYFS token, there are some bytes that likely control the partition sizes.

FACTORYFS

803 : A2 04 : 41476

512 : 7A 04 : 31236

513 : CA 04 : 51716

DBDATA

803 : F0 01 : 61441

512 : 18 02 : 6146

513 : C8 01 : 51201

CACHE

803 : 8C

512 : 8C

513 : 8C

MODEM

803 : 32

512 : 32

513 : 32

So there we have it. The only real changes between the PIT files are some seemingly garbage header information in 512/513 that is missing from 803, and FACTORYFS and DBDATA have different numbers -- probably sizes.

So assuming FACTORYFS maps onto /system, we can see that the only differences in the PIT files is moving space back and forwards between /dbdata and /system. The numbers themselves don't mean anything to me - can anybody work it out? :D
[Galaxy S I9000 Android Development] sztupy:
The numbers are little-endian, so you need to read them backwards per bytes. So instead of A12 it's actually 120A, etc. If you do so, you can see that the difference between 803 and 512 are actually minor, 40 "units" are shifted between probably DBDATA and SYSTEM.

Btw: doesn't the heimdal project klnow something about the pit files?
[Galaxy S I9000 Android Development] RyanZA:
Nice, that gives us

FACTORYFS

803 : 04 A2 : 1186

512 : 04 7A : 1146

513 : 04 CA : 1226

DBDATA

803 : 01 F0 : 496

512 : 02 18 : 536

513 : 01 C8 : 456

1186+496=1682

1146+536=1682

1226+456=1682

So we have a match. :)

Now to work out why the fat.format can work with 536, but not with 496

EDIT: Also, need to determine why some roms require certain PIT files. Only possibility I can see is that junk in the header - could be some type of allow list for firmwares. The 803 PIT should therefore work on all firmwares, since it just has 00s. Maybe. :)
[Galaxy S I9000 Android Development] RazvanG:
In 803.pit (compared to the .512 one) the system partition size has been increased by 10MB, while DBDATA partition size has been decreased the same amount (10MB).

PS: Dump the BML2 partition. The dump contains current partition mapping.

Hope this helps :)
[Galaxy S I9000 Android Development] sztupy:
I think the main cause is that some firmwares simply don't fit in the space reserved for them. Some of the m have larger system, some of them have larger dbdata partitions. Only a guess though, I think I start flashing pit files just for fun...
[Galaxy S I9000 Android Development] sztupy:
10MB = 40 units... That would give us 1 unit = 256kbyte. Nice.
[Galaxy S I9000 Android Development] sztupy:
So this means:

BOOT (bml01) = 01 = 1 = 0.25 MB (bootloader)

PIT (bml02) = 01 = 1 = 0,25 MB (the partition table)

EFS (bml03) = 28 = 40 = 10 MB (imei data and such)

SBL (bml04) = 05 = 5 = 1,25 MB (secondary bootloader)

SBL2 (bml05) = 05 = 5 = 1,25 MB (secondary bootloader backup)

PARAM (bml06) = 14 = 20 = 5 MB (the images shown when something is wrong)

KERNEL (bml07) = 1E = 30 = 7,5 MB (kernel image)

RECOVERY (bml08) = 1E = 30 = 7,5 MB (kernel image backup)

FACTORYFS (bml09) = 47A = 1146 = 286,5 MB (/system)

DBDATA (bml10) = 218 = 536 = 134 MB (/dbdata)

CACHE (bml11) = 8C = 140 = 35 MB (/cache)

MODEM (bml12) = 32 = 50 = 12,5 MB (software for wireless)

total: 501 MB
[Galaxy S I9000 Android Development] RyanZA:
Not sure how true this can be -- Take 512 vs 513 for example. Newer Eclair roms stopped working on 513, and required 512. However, 513 has a smaller dbdata and larger system than 512. Since we know that a clean rom when flashed has a /dbdata of around 2mb, or 1% or so of available space, it can't be space related.

Must be more to than simple space allocations.

EDIT: And 501MB means we have space left over. Where is it hiding?
[Galaxy S I9000 Android Development] sztupy:
Yes, but the flashed dbdata.rfs was probably actually a large partition, that didn't fit into the allocated space.

Yes, the missing 11MB is strange, unless there is a 1MB "safety" gap between two partition (12 partitions = 11 gaps), or some other data.

EDIT: No, dumped BML0, it's only 501MB in length. The missing part might still be some space needed for the BML and STL to work.
[Galaxy S I9000 Android Development] dillovic:
Hi. I'm sorry for hijacking this thread but I need professional help from some geniuses (genii) and apparently you guys are firmware gurus.

Once you guys figure out how PIT files work, can you please help me figure out how to force flash Korean firmware onto an international phone without bricking it? The reason why I would like to do this, is because the Korean version has some really nice features for example native call recording (3rd party call recorders have bad quality). I made a thread for it here

Thanks a lot, köszönöm szépen!
[Galaxy S I9000 Android Development] Richthofen:
Galaxy S I9000 PIT structure:

512.pit

PBL: 256KB (Primitive Bootloader)

PIT: 256KB

EFS: 10240KB (Non Volatile Memory)

SBL(1): 1280KB (Primary)

SBL(2): 1280KB (Backup)

PARAM: 5120KB

KERNEL(1): 7680KB (Primary)

KERNEL(2): 7680KB (Backup)

FACTORYFS: 293376KB

DBDATAFS: 137216KB

CACHE: 35840KB

MODEM: 12800KB

Total: 513024KB

513.pit

PBL: 256KB

PIT: 256KB

EFS: 10240KB

SBL(1): 1280KB

SBL(2): 1280KB

PARAM: 5120KB

KERNEL(1): 7680KB

KERNEL(2): 7680KB

FACTORYFS: 313856KB

DBDATAFS: 116736KB

CACHE: 35840KB

MODEM: 12800KB

Total: 513024KB

803.pit

PBL: 256KB

PIT: 256KB

EFS: 10240KB

SBL(1): 1280KB

SBL(2): 1280KB

PARAM: 5120KB

KERNEL(1): 7680KB

KERNEL(2): 7680KB

FACTORYFS: 303616KB

DBDATAFS: 126976KB

CACHE: 35840KB

MODEM: 12800KB

Total: 513024KB

In case there is backup blocks (e.g SBL and Kernel, Odin flashes them both while executing the flashing process).
[Galaxy S I9000 Android Development] Richthofen:
Galaxy S M110S is completely different hardware.

All other I9000 variants use Infineon X-Gold 616 baseband (Modem), while M110S uses Qualcomm baseband chip.
[Galaxy S I9000 Android Development] sztupy:
Made a try modifying the PIT file, to add more space to /dbdata and take away space from /system. I added around 25MB extra space to /dbdata.

Wasn't that hard actually, and I didn't encounter many problems (except the fact that the values are for the bare bml device, from which the stl has an extra 4-10% overhead so instead of the originally planed 35MB I could only spare 25).

If anyone's interested I can upload the modified pit and rom files.

Some remarks / questions:

- If we use the bare BML device instead of the STL I know we lose wear leveling (at least according to the rfs docs from samsung), but can't we use yaffs or similar on those devices? Or what if we (can we?) use cramfs for the /system on the BML, to gain even more space we could use for the /dbdata partition?

- The overhead the STL has seems a bit random to me. /system and /dbdata has a 4% overhead, while /cache a 10% one.
[Galaxy S I9000 Android Development] hardcore:
I'd be careful about resizing the partitions manually. Samsung should have aligned the partitions for best performance.

I'm not sure if its a placebo, but PIT 512 seems faster to me than PIT 803.
[Galaxy S I9000 Android Development] RyanZA:
Aligning should not be terribly hard -- we already specify using 256kb pieces instead of raw bytes. The alignment therefore is somewhere between 256kb and 4mb. If we align for 4mb, we align for everything smaller too. So as long as the numbers used are cleanly divisible by 4*4=16, it will be correctly aligned.

Flashing a PIT file with repartition checked seems to (according to docs) reset the wear leveling (the current record of what was written where, I guess), so you should not tick repartition if you are flashing many times in a row. (Many times is probably some very big number.)

I can't see why we couldn't use YAFFS or similar filesystem. Might work really well. I've got no experience setting up YAFFS though, and I don't believe it is trivial.
[Galaxy S I9000 Android Development] vitalij:
I wonder if it is possible to make very small /system partition, and move it to mmcblk0 - since it is read only, performance will be ok. And make large dbdata partition, and keep /data/data there. That may be the ultimate lag fix :)
[Galaxy S I9000 Android Development] RyanZA:
It is possible, but how would you flash a firmware then?

We are quickly approaching the 'throw it all away, and start from scratch with our own tools and bootloader. :D
[Galaxy S I9000 Android Development] fane1:
So are u guys planning to release the new galaxy s series phone?? :D:D

You should rename it to galaxy-xda :)
[Galaxy S I9000 Android Development] huxflux2003:
So, from the info you have gathered, is there any point in using a PIT file when repartition is not checked?
[Galaxy S I9000 Android Development] dupel:
I don't really see much point, but than again PIT file will tell odin (if your flashing pda) explicitly where the kernel should be flashed.

Also, I noticed that kernel partition is only 7.5-6 mb. Doest it mean that we cant use larger kernels (cos I think voodoo might me larger - hence the screen tear on boot).
[Galaxy S I9000 Android Development] FadeFx:
I already flashed a full firmware without using any pit file, so there is no need for it when not ticking repartition...
[Galaxy S I9000 Android Development] Richthofen:
If the pit file and re-partition is not selected, the excisting pit will be used.

Unless you use a special version, you actually never need to re-partition.

512.pit (which is always used as default by Samsung) will work with any current firmware.
[Galaxy S I9000 Android Development] Odia:
Based on PIT s1_odin_20100512.pit

1 blk = 40000 (256KB)

Partition Name	START	LEN

BOOT	00000000	0000	0003FFFF	0001

PIT	00040000	0001	0003FFFF	0001

EFS	00080000	0002	009FFFFF	0028

SBL	00A80000	002A	0013FFFF	0005

SBL2	00BC0000	002F	0013FFFF	0005

PARAM	00D00000	0034	004FFFFF	0014

KERNEL	01200000	0048	0077FFFF	001E

RECOVERY	01980000	0066	0077FFFF	001E

FACTORYFS	02100000	0084	11E7FFFF	047A

DBDATAFS	13F80000	04FE	085FFFFF	0218

CACHE	1C580000	0716	022FFFFF	008C

MODEM	1E880000	07A2	00C7FFFF	0032

07D4	1F500000
[Galaxy S I9000 Android Development] FadeFx:
Existing pit means the partitioning like it already is on the phone, or the pit file last loaded by Odin? So if i flash one phone with 512 pit, and then flash a phone that was previously flashed with 803 pit, using no pit, it uses 512 or 803? If it uses 803 this means it just takes the partitions as they are on the phone...
[Galaxy S I9000 Android Development] sztupy:
According to my tests the screen tears start appearing after around 6,2-6,3MB. The larger the kernel the more snowing will appear at boot (I tried with a 7MB kernel, the blue lines almost erased the galaxy s logo).
[Galaxy S I9000 Android Development] sztupy:
Btw. I don't think odin uses the pit file if you don't check re-partition. Imho it simply dumps /dev/block/bml2 and uses tha information stored there. That's why flashing works if you don't use a pit file, or use an incompatible pit file.
[Galaxy S I9000 Android Development] sztupy:
In the 512 pit, the /system starts at 33mb, and the /dbdata doesn't even start on an integer mb location, so I think you can use anything. (and yes, the numbers actually align them to 256kbyte boundaries)

512 pit has more space for dbdata, which is propably good if using a lot of apps.
[Galaxy S I9000 Android Development] hardcore:
There is already a pit file in the phone which odin will use. So u don't need to choose one in odin.
[Galaxy S I9000 Android Development] Richthofen:
IMO the dbdata on I9000 is way oversized.

Samsung actually stores the sample video and mp3 to dbdata when a "low" firmware package is used. They take over 80MB in total.
[Galaxy S I9000 Android Development] RyanZA:
100% true, I believe. /dbdata seems to confuse a lot of people - there is no real application data stored here, only config files for system apps. It could probably be 5mb or so without issue.

Richthofen, do you know why some partitions are duplicated? Is there a reason, or are we free to change those? AFAIK when booting normally, it will use the KERNEL part, and call /init on startup. When booting into recovery, it will use RECOVERY part, and call /recovery on startup. Therefore, having a dedicated RECOVERY image seperate from the KERNEL image means that we could save ~1mb or so of ram by taking the recovery binary out of KERNEL.

(The KERNEL is loaded completely into ram on booting, so minimizing the size of KERNEL will give you more available ram for everyday usage. Those MP3 files telling you how conversion worked in Voodoo? They are loaded permanently into ram and cannot be removed, costing you application memory. EDIT: Same for CFRoot method of rooting - the su binary, superuser.apk and busybox binary are loaded permanently into ram, costing you ~2mb of application memory.)
[Galaxy S I9000 Android Development] sztupy:
unless you bind /data/data to /dbdata. Then it's actually undersized...
[Galaxy S I9000 Android Development] Richthofen:
The duplicates are for backup purposes only I recon.

Atleast SBL(2) at BML5 should be because the PBL checks if SBL(1) at BML4 is valid. If it is -> execute SBL(1) from BML4, else SBL(2) from BML5.

I think we could easily take about 20MB (or more) away from the cache partition.

The largest CSC I´ve seen is about 15MB.
[Galaxy S I9000 Android Development] sztupy:
In froyo the cache partition is used for the browser and for the market, so that wouldn't be a good idea.
[Galaxy S I9000 Android Development] FadeFx:
do we actually need a csc? i think it just contains bloatware and nothing really needed for the firmware to run, right?
[Galaxy S I9000 Android Development] frauhottelmann:
As far as I know, it contain carrier information such as APNs, Am I right? (not that my APN can be found anywhere, I always use my APN Backup...)
[Galaxy S I9000 Android Development] sztupy:
the simcard won't be recognized if there is no csc present. Although yeah most csc's only contain apns + some carrier specific bloatware.
[Galaxy S I9000 Android Development] FadeFx:
so maybe we could provide a "minimum csc" just containing cyanogens apn list and what ever is needed for the phone to run
[Galaxy S I9000 Android Development] RyanZA:
Not true, simcard works fine without csc.
[Galaxy S I9000 Android Development] EarlZ:
That means its ok to flash w/o a CSC?
[Galaxy S I9000 Android Development] jeebspawnshop:
Just cuz the simcard works without a CSC, doesn't mean that it'll work properly :P

The CSC tells the phone which frequencies to use and contains emergency numbers for the specific country.

BUT! This is info I've gathered from the forum, not pro knowledge.

On the other hand, I guess if you type *#2263# you can just set the frequencies manually...

EDIT: I realize I just steered the thread away from the topic. Apologies! I wanna know more about PITs! sztupy and RyanZA, you guys are my favuritest peeples evar.. surslee ;)
[Galaxy S I9000 Android Development] Richthofen:
CSC has nothing to do with the frequencies which the phone will / or be able to use.

Frequencies are defined by the baseband (modem) firmware.

CSC = Customer Specification Configuration.

It defines the default settings (default language, time format, whenever the haptic is on, SOS numbers, etc), APNs and adds branding to the phone (if thats the case).

There is nothing "mystical" in it.
[Galaxy S I9000 Android Development] RyanZA:
Emergency numbers sounds possible, but frequencies can't be right. Those are set by the radio image, not the csc image.

As far as the PIT file issue - we seem to be at the limit of easily obtainable information.

We now know how to modify PIT files to move STL partition sizes around, so that's good. :D

We think the extra header info in the 512/513 PIT may have something to do with which roms can be flashed, or it may be space related. Easy way to check: 00 out the extra header information in the 513 PIT, and see if it can now flash a previously non-compatible rom. :)

We don't know much about how the 'KERNEL' etc symbols actually match up when on the device. Are the symbol mappings being done exclusively in Odin, or is the bootloader doing something? Both bootloader and Odin are closed source, so we might never find out.

We know that the fat.format utility not working has nothing to do with the PIT file itself, but with the size it makes partitions - certain sizes probably make it difficult for fat.format utility's default settings to work. Should be easy enough to determine by tweaking the defaults slightly one by one until we find which one works to fix it. Maybe. Or I guess we can just use busybox's mkfs.vfat.

At any rate, progress. :D
[Galaxy S I9000 Android Development] sztupy:
When I forgot to install a csc file, I couldn't get the sim card to boot up. In logcat I found a lot of lines from the phone service that complained about the missing CSC files, and eventually it wouldn't start. It doesn't contain anything mystical, but if some of the services can't start up because it's missing then it's needed.
[Galaxy S I9000 Android Development] DamianGto:
Its nice that you guys has confirmed what i always think the pit file was for.

The question now is how much space we need on the different places.

Many if we free up some space for the kernel we might can start to make more advanced kernel.

Sent from GT-I9000 Jpm OS kernel with z4mod
[Galaxy S I9000 Android Development] jeebspawnshop:
I was eating a sandwich while watching Modern Family, and it hit me;

PIT = Partition Information Table

Another useless post by your friend, Jeebs ;)
[Galaxy S I9000 Android Development] DamianGto:
Well that's the name. Pit is a short name. Lol

Sent from GT-I9000 Jpm OS kernel with z4mod
[Galaxy S I9000 Android Development] EarlZ:
I believe it works properly but you may have to do some manual configuration on your own, I've been flashing F/W using a CSC not specific to my region and everything works well. My region CSC is root locked >.<
[Galaxy S I9000 Android Development] Tyxerakias:
Quick question: how can someone who hasn't used a pit file check his partition info and especially the bml sizes to check which pit file his firmware is using?
[Galaxy S I9000 Android Development] KMino:
Just my experiance from the last few weeks. Yes it has been fun and painful learning the innards of the system again, but on a phone!

Had JP6 installed with 803 pit file from Odin, things seemed fine, but did experience a few FC's in some apps, but mostly in NFS Drift.

Changed to Tayutama Edition v1.0.2 (I9000) (EXT4, then conv to JPS) it still did the same as before with FC's. Yes did a FR and all that :)

Was fed up with the FC's in NFS Drift and when doing a lot of multitasking. So I went into recovery and Odin and did a fresh install of JPM but with a 512 pit file. Then installed CWR and installed Tayutama Edition v1.0.2 (I9000) (I choose JFS again, no loop, like before;).

Basicaly haven't had a single FC since in NFS Shift or in any other apps since then!

Only other difference is I have all four of the system tweaks turned on and a working CSC for my region now. So something was up in there somewhere. :| Either the pit or the conversion process did something weird, although I did install the apps again incase it did corrupt them during conversion.

BTW, JFS rocks my boxers!
[Galaxy S I9000 Android Development] sztupy:
You can dump /dev/block/bml2 and compare it's first few bytes to the pit files. Or check the sizes in /proc/partitions, mainly the bml9 and bml10. Those are the only things changed between pit files iirc.
[Galaxy S I9000 Android Development] Tyxerakias:
Fantastic, thanks a lot sztupy :)