Database Info

Custom partition layouts, ZERO brick risk!

This is about the coolest thing you can imagine.
DEATHSPL is OBSOLETE.
We can repartition these things -- to ANY layout we like -- withOUT changing or modifying the SPL!
This is even compatible with a STOCK SPL! I.e. 0.95.0000.
This is something I discovered while looking at the MTD drivers.
The mtd drivers accept partition table specified on the KERNEL COMMAND LINE! And this SUPERSEDES the automatic table discovery method.
This is the command line argument for STOCK partition layout:
Code:
mtdparts=msm_nand:[email protected](misc),[email protected](recovery),[email protected](boot),[email protected](system),[email protected](cache),[email protected](userdata)
You can boot a kernel with a modified partition table using one of two methods;
the "-c" parameter to fastboot allows you to add kernel parameters. This is good for booting RECOVERY images and applying custom layouts.
The second method is to build the custom layout into your boot.img or recovery.img.
This can be done using the "--cmdline" parameter to mkbootimg.
Notes: The smallest possible partition is 128k.
The partition sizes must be MULTIPLES of 128k and must start on an offset that is a multiple of 128k. The memory size is 256MB precisely.
Note: DO NOT modify ANYTHING before the START of the boot partition, i.e. offset 0x2bc0000. If you do, it won't boot!
***** EDIT:
We now have a BETA implementation of this concept: http://forum.xda-developers.com/showpost.php?p=6916491&postcount=39
Thanks go to Firerat, who did the actual implementation work in converting CM 5.0.8 to this process.
Also thanks to skraw at CM forums who asked a silly question that started the gears a crankin and ended up getting this as an answer.
** just goes to show that there is no such thing as a stupid question.

Sweet stuff!
Now we can finally reduce the size of that useless cache partition. And ROM devs can actually fit anything they want without a headache.
This should be leaps and bounds more useful on the phones with more ROMs space like the 32A Magic, where the cache is absurdly large.

xaueious said:
Sweet stuff!
Now we can finally reduce the size of that useless cache partition. And ROM devs can actually fit anything they want without a headache.
This should be leaps and bounds more useful on the phones with more ROMs space like the 32A Magic, where the cache is absurdly large.
Click to expand...
Click to collapse
I'll ask a silly question, and full intent not to derail the thread.. why have partitions at all? (do they accomplish some level of protection that simple unix privs do not if /system, /data, /cache, etc were all on the same partition?) Hopefully not a super stupid question (I understand their use on my home linux box, but fail to see what value they add here)

I already pointed this out months ago.. but no one ever tried to make a use out of it.

sweeeeeet! good ****, someone make sure cyanogen knows about this.

mhmm... this is awesome! But for all those who already have Death SPL, could this increase the amount of space even further?

mattv888 said:
mhmm... this is awesome! But for all those who already have Death SPL, could this increase the amount of space even further?
Click to expand...
Click to collapse
Yeah Im curious about that too

mattv888 said:
mhmm... this is awesome! But for all those who already have Death SPL, could this increase the amount of space even further?
Click to expand...
Click to collapse
Yes, in theory.. I'm not sure how usable it would be, but purely theoretically you should be able to drop cache and userdata to 128k, mount them both on the sdcard instead and flash a 200mb+ system image.
With a bit of modification to the way we flash images at the moment, there's no reason devs can't include a custom partition layout to fit the requirements of every release.
This is an awesome find by both lbcoder and maxisma, who seem to have discovered it independently.. I totally missed maxisma's annoucement though
Whoever found it first, this rules.

This would be really awesome to see can't wait

Macrophage001 said:
This would be really awesome to see can't wait
Click to expand...
Click to collapse
Wait for what?
This is something that everyone can do for themselves!
All you need is a calculator (to calculate memory offsets and sizes), the first post of this thread, and this:
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
unpack your boot.img, mkbootimg it back with the specified kernel command line, shove it into your update.zip (or fastboot it into the phone), and you're done-ish.
Take the most recent CM for example:
1) extract boot.img, unpack it, repack it with the kernel command line specified (modified to your specifications), put it back in the update.zip, resign, and put it on your sdcard.
2) Phone in fastboot mode, fastboot -c "same kernel command line as boot.img is packed with" boot recovery.img, flash your update.zip, done.
And then every time the phone boots up, it'll have the customized partition table since it is built into the boot.img.

with this custom partition layouts, do we also need to do something to the recovery to make nandroid/bart recognize the new layout?

haozheng91 said:
with this custom partition layouts, do we also need to do something to the recovery to make nandroid/bart recognize the new layout?
Click to expand...
Click to collapse
Same steps as the rom, just ensure you *never* flash *any* spl or radio for any reason from a re-partitioned recovery with a cache partition that does not match the spl's actual cache start location. Or you will be in the market for a jtag adapter to fix your brick.
Making this user friendly will need some configuration work.

ezterry said:
Same steps as the rom, just ensure you *never* flash *any* spl or radio for any reason from a re-partitioned recovery with a cache partition that does not match the spl's actual cache start location. Or you will be in the market for a jtag adapter to fix your brick.
Making this user friendly will need some configuration work.
Click to expand...
Click to collapse
There's security built in to that process....
the cache partition has to get a special header applied in order for the update to be taken, and if the spl or radio partition was mapped differently, this header will be badly broken. I believe that there are also checksums on the spl and radio images that should be checked by the SPL prior to actually installing them. Part of the reason for this is to ensure that the image was actually written correctly to the cache partition.

Another good find.
maxisma said:
I already pointed this out months ago.. but no one ever tried to make a use out of it.
Click to expand...
Click to collapse
Don't see why. Hopefully people will be able to understand how to do this, get rid of the deathspl along with all the spam topics that come from the resulting bricks.

lbcoder said:
There's security built in to that process....
the cache partition has to get a special header applied in order for the update to be taken, and if the spl or radio partition was mapped differently, this header will be badly broken. I believe that there are also checksums on the spl and radio images that should be checked by the SPL prior to actually installing them. Part of the reason for this is to ensure that the image was actually written correctly to the cache partition.
Click to expand...
Click to collapse
I can test it but I've seen invalid radio images trap a phone in flash radio.. I highly recommend just not tempting fate with this one and just installing 1.33.2003 or 1.33.2005 before starting custom partitions.. then you can deal with radio/alt recovery flashes from there.
Leave the recovery for android system install/uppdate/backup operations.

any success?

ezterry said:
I can test it but I've seen invalid radio images trap a phone in flash radio.. I highly recommend just not tempting fate with this one and just installing 1.33.2003 or 1.33.2005 before starting custom partitions.. then you can deal with radio/alt recovery flashes from there.
Leave the recovery for android system install/uppdate/backup operations.
Click to expand...
Click to collapse
Possibly with an invalid radio, but DEFINITELY NOT with an offset-cache partition. It simply can't possibly do anything without the right header.
And I don't see any benefit at all for installing a 1.x SPL. The ability to flash radio or SPL direct depends on fastboot, and if you have fastboot, you can break the update-x cycle simply by wiping the misc partition.
And for that matter, the 0.95.0000 SPL withOUT fastboot still could flash an nbh file in any circumstance where any of the engineering/pseudoengineering SPLs could enter fastboot.
Tempting fate is to flash a radio or spl to begin with. If you want to feel really safe, you can always build a recovery that lacks the ability to flash the radio or spl. This would, of course, force you to go back to the SPL's partition table (i.e. another recovery) to flash either of those.
Or how about this: query the kernel command line -- if the partition table is set on the kernel command line, don't allow flashing of radio or spl.

lbcoder said:
This is the command line argument for STOCK partition layout:
Code:
mtdparts=msm_nand:[email protected](misc),[email protected](recovery),[email protected](boot),[email protected](system),[email protected](cache),[email protected](userdata)
Notes: The smallest possible partition is 128k.
The partition sizes must be MULTIPLES of 128k and must start on an offset that is a multiple of 128k. The memory size is 256MB precisely.
Note: DO NOT modify ANYTHING before the START of the boot partition, i.e. offset 0x2bc0000. If you do, it won't boot!
Click to expand...
Click to collapse
I'm working my way thru the math.. I set up an OpenOffice spreadsheet (alas its fairly inept at working with hex #'s, so I have to do all the match in decimal and convert it to hex (couldn't find a way to make it add in hex, and it can't seem to convert big hex numbers back to dec.. even tho it can convert that same dec # into hex... grr...) anyway... this is the table I came up with (using D and H to denote Decimal and Hex versions of the same #s)
Code:
Block k M bytes(D) bytes(H) StartD EndD StartH EndH
misc 256 0.25 262144 40000 38535168 38797312 24C0000 2500000
recover 5120 5 5242880 500000 40632320 45875200 26C0000 2BC0000
boot 2560 2.5 2621440 280000 45875200 48496640 2BC0000 2E40000
system 69120 67.5 70778880 4380000 48496640 119275520 2E40000 71C0000
cache 69120 67.5 70778880 4380000 119275520 190054400 71C0000 B540000
userdat 76544 74.75 78381056 4AC0000 190054400 268435456 B540000 10000000
size 229900288 219.25
The only "gap" I saw was after misc.. ie. there was space between the end of misc and the beginning of recovery (1792k by my calculations).. is that correct, or did I fudge my math up? Any idea what is in that gap?
Also by taking the final addr and subtracting the start addr, it looks like 219.25M (out of the 256M you mention) are being used? (actually that does not take the "gap" memory into account). Any idea what is using the other 256-219.25=36.75M?
Note: not trying to poke any holes here.. I'm trying to get a good understanding of this, so I can give it a try.
EDIT: added M column to table

Yes.. there are some internal partitions after misc.
If you have 1.33.2005 or 1.33.2003 spls ask it the partition layout yourself: fastboot oem listpartition

zim2dive said:
I'm working my way thru the math.. I set up an OpenOffice spreadsheet (alas its fairly inept at working with hex #'s, so I have to do all the match in decimal and convert it to hex (couldn't find a way to make it add in hex, and it can't seem to convert big hex numbers back to dec.. even tho it can convert that same dec # into hex... grr...) anyway... this is the table I came up with (using D and H to denote Decimal and Hex versions of the same #s)
Code:
Block k M bytes(D) bytes(H) StartD EndD StartH EndH
misc 256 0.25 262144 40000 38535168 38797312 24C0000 2500000
recover 5120 5 5242880 500000 40632320 45875200 26C0000 2BC0000
boot 2560 2.5 2621440 280000 45875200 48496640 2BC0000 2E40000
system 69120 67.5 70778880 4380000 48496640 119275520 2E40000 71C0000
cache 69120 67.5 70778880 4380000 119275520 190054400 71C0000 B540000
userdat 76544 74.75 78381056 4AC0000 190054400 268435456 B540000 10000000
size 229900288 219.25
The only "gap" I saw was after misc.. ie. there was space between the end of misc and the beginning of recovery (1792k by my calculations).. is that correct, or did I fudge my math up? Any idea what is in that gap?
Also by taking the final addr and subtracting the start addr, it looks like 219.25M (out of the 256M you mention) are being used? (actually that does not take the "gap" memory into account). Any idea what is using the other 256-219.25=36.75M?
Note: not trying to poke any holes here.. I'm trying to get a good understanding of this, so I can give it a try.
EDIT: added M column to table
Click to expand...
Click to collapse
You don't need to do any subtraction. The start address is itself the size of the "gap" before it. I.e. look at startD column: 38535168 -- that would be ~38.5 MB or (divide by 1024x1024) 36.75 MiB, the same as the number you got through your subtraction.
That gap is for the radio and SPL, and some proprietary data, like IMEI, radio lock, security, etc.
Of course, you could just ASK someone who has a deathSPL for the numbers....
Not about the gap between misc and recovery: I believe that the splash images go there.
In any case, you don't need to worry about any of those....
The only partitions you need to map are the ones that *are* mapped.
misc, recovery, and boot should be left alone. As should the STARTING address of system.
You should start by adjusting the SIZE of system,
Adjust the OFFSET of cache by the SAME AMOUNT as you adjusted the SIZE of system.
Adjust the SIZE of cache by whatever you feel is appropriate,
Adjust the OFFSET of userdata to (OFFSET+SIZE) of cache.
And according to the mtd documentation, you should be able to set the SIZE of userdata to "-" in order for it to fill all of the remaining space. Either that, or hardcode it to 0x10000000-OFFSET.

[Q/A] Kernel 3.x Discussion thread

Kernel 3.x is now having progress again, updating the thread!​
Hey guys, i noticed that the new thread for Kernel 3.x developement is getting spammed a little, so please post anything not related to development here.
I will also include latest updates including a small faq (i will add more when you guys ask questions).
Current members working on the project:
hillbeast
dhiru1602
crackerizer
Latest News: (First is newest)
Current issue: Kernel is booting but crashing, still in stage 1.
hillbeast said:
Isn't patience a virtue...?
Code:
Uncompressing Linux... done, booting the kernel.
<6>Initializing cgroup subsys cpu
<5>Linux version 3.0.8+ ([email protected]) (gcc version 4.4.3 (GCC) ) #Test PREEMPT Mon Sep 24 11:09:01 NZST 2012
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: LGE Hub board
<6>Reserving 4194304 bytes SDRAM for VRAM
Memory policy: ECC disabled, Data cache writeback
<6>OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk )
<6>SRAM: Mapped pa 0x40208000 to va 0xfe408000 size: 0x7000
<7>On node 0 totalpages: 62976
<7>free_area_init_node: node 0, pgdat c06cbb8c, node_mem_map c083f000
<7> *Normal zone: 512 pages used for memmap
<7> *Normal zone: 0 pages reserved
<7> *Normal zone: 62464 pages, LIFO batch:15
<6>Clocking rate (Crystal/Core/MPU): 26.0/400/800 MHz
<6>Reprogramming SDRC clock to 400000000 Hz
<7>pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
<7>pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping on. *Total pages: 62464
<5>Kernel command line: console=ttyS2,115200 videoout=omap_vout omap_vout.video1_numbuffers=6 omap_vout.vid1_static_vrfb_alloc=y omapfb.vram="0:4M" version=Sbl(1.0.0) 2011-03-21 10:46:47 androidboot.mode=jig bootmode=0 androidboot.current_panel=0
<6>PID hash table entries: 1024 (order: 0, 4096 bytes)
<6>Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
<6>Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
<6>Memory: 246MB = 246MB total
<5>Memory: 238620k/238620k available, 23524k reserved, 0K highmem
<5>Virtual kernel memory layout:
* * vector *: 0xffff0000 - 0xffff1000 * ( * 4 kB)
* * fixmap *: 0xfff00000 - 0xfffe0000 * ( 896 kB)
* * DMA * * : 0xffc00000 - 0xffe00000 * ( * 2 MB)
* * vmalloc : 0xd0800000 - 0xf8000000 * ( 632 MB)
* * lowmem *: 0xc0000000 - 0xd0000000 * ( 256 MB)
* * pkmap * : 0xbfe00000 - 0xc0000000 * ( * 2 MB)
* * modules : 0xbf000000 - 0xbfe00000 * ( *14 MB)
* * * .init : 0xc0008000 - 0xc003d000 * ( 212 kB)
* * * .text : 0xc003d000 - 0xc0674d5c * (6368 kB)
* * * .data : 0xc0676000 - 0xc06cc500 * ( 346 kB)
* * * *.bss : 0xc06cc524 - 0xc083ed88 * (1483 kB)
<6>Preemptible hierarchical RCU implementation.
<6>NR_IRQS:410
<6>IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts
<6>Total of 96 interrupts on 1 active controller
<6>OMAP clockevent source: GPTIMER1 at 32768 Hz
<6>sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
<6>Console: colour dummy device 80x30
<6>Calibrating delay loop... <c>798.24 BogoMIPS (lpj=3117056)
<6>pid_max: default: 32768 minimum: 301
<6>Mount-cache hash table entries: 512
<6>Initializing cgroup subsys debug
<6>Initializing cgroup subsys cpuacct
<6>Initializing cgroup subsys freezer
<6>CPU: Testing write buffer coherency: ok
<4>omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_core
<4>omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_per
<4>omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_wkup
<4>omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for usbhs_ohci
<4>omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for usbhs_ehci
<4>omap_hwmod: gpt12_fck: missing clockdomain for gpt12_fck.
Click to expand...
Click to collapse
hillbeast said:
Further Information About 'Blind SBL'
As I can't see the SBL, it does limit things until I figure out why it won't display anything, however I won't let Samsung beat me like that, and I progressed by hex viewing the SBL partition on the OneNAND, and I found something interesting:
Code:
andr_load_normal..Load Android Normal-boot image from the flash device..andr_load_recovery..Load Android Recovery-boot image from the flash device..andr_load_kernel..Load Android Kernel and Ramdisk using the current boot-up reason
hillbeast said:
Oh wow I didn't expect it to be that easy. I just took another kernel (I used BCK seeing it works on GB), renamed normalboot.img to recovery.img, put it back in a tar and flashed it with Odin, then went into the blind Sbl, typed andr_load_recovery [enter] boot [enter] and away it went. Obviously I had no UART apart from decompression seeing BCK doesn't support UART, but going into Settings > About Phone > and seeing XDA_BAM in there when I hadn't touched the normal kernel was quite cool. So that's how you dual-boot on a GSL.
Click to expand...
Click to collapse
Trying to decipher it, this seems to be the output of the help command, and these three commands seem interesting, as they seem to allow booting the normal kernel (.img), or the recovery kernel. I'll try flashing something different in the recovery partition and see what it does. I'll try flashing something like the CM9 kernel. If I can get this figured out then perhaps if someone is daring enough to mod the SBL, we could get a working recovery partition. The functionality appears to be there, so I can't see why not.
Click to expand...
Click to collapse
hillbeast said:
Okay so I backported the new CMDLINE functions from kernel 3.x and it works sweet. Great to FINALLY see a proper UART output on this device. I need to make a few touch-ups, namely to giving UART console root access. And I need to charge the phone up... I haven't charged it all weekend and the battery is really flat.
Click to expand...
Click to collapse
hillbeast said:
YES! SUCCESS! By forcing the boot command line to 'console=ttyS2,115200' I managed to get to the UART console. This is much more useful than just like 20 lines of output then nothing. However, there is a problem with this: with this change, I don't have the normal commands coming through and they are important. They set stuff like the framebuffer RAM, what bootmode to be using, etc. Without that, the phone is kind of a rock.
I will see if I can backport the function from newer kernels that allows you to combine the provided commands from the bootloader with your own commands.
Click to expand...
Click to collapse
hillbeast said:
Right so after a bit of poking around, I've been trying to figure out what the exact device is that external UART uses. It's really frustrating not knowing this because it means I can't figure out why there is no output (or at least legible output after the UART drivers start), so I tried sending 'hi' to ttyS0, S1 and S2, and nothing came up, so I assumed that they must be locked or something. I then noticed after doing that, nothing was coming up on the UART at all. Before, I would get all sorts of garbage, but after that, I got nothing. I then tried one by one to see which device did this, and I found it was ttyS2: after sending 'hi' to ttyS2, it would stop showing stuff on the UART. This told me that external UART must be connected to ttyS2.
Now I then tan stty -F /dev/ttyS2 (to find the tty settings for this port), and got this output:
Code:
speed 9600 baud;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
flush = ^O; min = 1; time = 0;
-brkint -imaxbel
That first line, speed 9600 baud is a problem for me, as it should be 115200. I'm going to do more testing and see if it is outputting at 9600.
EDIT: Nope. Changing PuTTY to baud 9600 still shows garbage:
Code:
¨Ôþ°üýxÍùøXýñ±¥õÔþýMþ屡ÈÙÑ°ÑéÀÙi
ÐuÑÕ´üÔôÐÜ´ÀôÜ©Ñ ùªô(üÌù,Äü ÜÅuðÜå
øà°ù¡ùý ùåñ¤@è*EÐiáÅüÑôÐ&ôåå¤Ì ÝðØ*ñÿÄÿÁÀÐÀøüù
-Å©E*ÅùÔqÄÿYÕÀÁý±ÿ±ØôÀôÑôÑðÀôÑüÀøÑøÀøÑüÀøÀøÑøµÐø©ð¹ÌùÝôåþé°ÀñÜÑø½è*ÐÅ
ÿùøýõÈðýñÑØá*µÙñð´¦ÑÐØá°aÕáÑýÉØÐuÁÑ_´)Ôô
Üù¬üýÑØåýáÁØñ*¡Éññ¡_ÑÐÑÉÍÐ
ؾàyÐõ
Ø
ùµþ(,¨ý`
Click to expand...
Click to collapse
hillbeast said:
Another update, I did this in adb shell:
Code:
echo PDA > /sys/devices/platform/switch-sio/uart_sel
Then rebooted the phone with my UART cable attached and now I get this:
Code:
Uncompressing Linux... done, booting the kernel.
So it's giving me output up until the kernel boots which told me the console attribute in the cmdline isn't set. I looked and that confirmed it that it wasn't. I will get the sourcecode for a kernel and compile it with the console attribute.
So yes, this phone will do UART. I just have to do it a bit weirdly.
Click to expand...
Click to collapse
hillbeast said:
Update to this: got this output:
Code:
AST_POWERON
BOOTING COMPLETED
That's the modem speaking to me over UART. Gotta change the UART mode to PDA instead of MODEM. Will do that once I root the phone.
Click to expand...
Click to collapse
What needs to be done: (Updated 6/19/2012)
Everything
mach code (board-latona)
plat code
drivers
FAQ:
(Please read this before asking questions, if you ask an already answered question your post will be reported, and you won't get an answer.. because it's already here!)
*Is This using Linaro? (?)
-Yes(?)
*What's this Linaro thing all about? (?)
-It (could) make your android device twice as fast, no one is sure if it will really make a difference. (?)
*What's UART?
-This will basically allow hillbeast to debug the kernel while he is developing it.
*I heard about some changes to using ODIN..
With kernel 3.x you can still flash new kernels on ODIN.
With kernel 3.x you will not be able to use ODIN to flash a ROM which is designed for kernel 3.x (these will be highlighted when they are released) as these ROMs will be in a filesystem/block device structure that is compatible with ODIN (technical mumbo jumbo that I intentionally used to say that it's not going to work)
With kernel 3.x you can still flash an old 2.6.35 kernel back onto the phone.
With kernel 3.x you can still flash an old ROM that uses kernel 2.6.25 back onto the phone (Gingerbread/Froyo) to go back to stock versions, you just have to install the stock kernel as well at the same time
*When the 3.x kernel is released, can i use it with Samsung stock ROMs?
-No, this kernel will not include any samsung code, samsung ROMs expect samsung drivers.
Quote of the year from hillbeast : "NO SAMSUNG MORONIC CODE "
*When is da kenral gowin to beh released you no god man why no relse any tim me wunt kernal 3.x?!?!!!11!!1
-No ETA's!
*The LG optimus black has same board and configuration. will this help with the development of any ROM/kernel for the i9003?
-Looking at the board of the optimus, no its certainly not the same. Not even close. Where we have a OneNAND and an eMMC, the Black has a NAND, perhaps an eMMC. The layout of the board may not even be the same. Sure the components may be similar, but so are the specs of a Toyota Celica and a Lotus Exige.
*Can you add X and X feature in the new kernel ?
-Don't request new feature additions yet, devs are focusing on getting the kernel booting first.
*I think i can help!
-Go to the development thread here and apply to help!
Note, quote from hillbeast: Please don't put your hand up if you can't dedicate your phone to this. This will result in your phone being out of action quite a lot while we are testing, and if you need your phone 24/7 then you're going to need to keep flashing back. You will also NEED ODIN. Flashing from CWM is not an option.

Hello, I am actually not new around xda but never join any discussion and conversation. Got so many phone from Moto Milestone, HTC HD2, and latest was SGSII. Unfortunately got robbed by someone who broke my house and stole my SGSII, Galaxy Tab 10.1, and iPad2. So now just support my girlfriend phone to be more awesome and fast. hehe
So from what I understand is that UART is a debug tools that constantly tells us what happen when we are try to running any kernel? It will tells us whats wrong that the kernel cannot start?

It seems awesome. I cannot wait to see it in our mobile phones, it will be terrific. I believe you are doing great job with our phone an I think that Dhiru, and you now are the great developers of our mobile Phone; the unwanted brother of the SGS.

ajis90 said:
Hello, I am actually not new around xda but never join any discussion and conversation. Got so many phone from Moto Milestone, HTC HD2, and latest was SGSII. Unfortunately got robbed by someone who broke my house and stole my SGSII, Galaxy Tab 10.1, and iPad2. So now just support my girlfriend phone to be more awesome and fast. hehe
So from what I understand is that UART is a debug tools that constantly tells us what happen when we are try to running any kernel? It will tells us whats wrong that the kernel cannot start?
Click to expand...
Click to collapse
It will basically let him debug the kernel when he is developing it
juanfpo96 said:
It seems awesome. I cannot wait to see it in our mobile phones, it will be terrific. I believe you are doing great job with our phone an I think that Dhiru, and you now are the great developers of our mobile Phone; the unwanted brother of the SGS.
Click to expand...
Click to collapse
All thanks go to hillbeast and dhiru, i just made this discussion thread

Very nice work!
FAQ:
*Is This using Linaro?
-Yes.
Click to expand...
Click to collapse
Wow, I am pretty sure this kernel will make our phone fly!

can someone tell what is linaro ??

m hoping kernel 3.0 will finally make the gpu overclock work ! after that we wont have any lags at all n like hillbeast said no samsung moronic code i couldnt agree more with him

anuraagkochar said:
can someone tell what is linaro ??
Click to expand...
Click to collapse
Basically, it improves the state of Linux on the ARM platform, and also it optimizes up a stock Android twice as fast as stock Android.
http://arstechnica.com/gadgets/2012...e-boosted-30-100-percent-by-linaro-toolchain/

will kernel 3 ever improve our battery life in our dearest cm9?

marshygeek said:
will kernel 3 ever improve our battery life in our dearest cm9?
Click to expand...
Click to collapse
Not sure about that, but the current battery performance on the CM9 is awesome already, lasts 2 days with moderate use, if you get less there are different factors:
-You use your phone too much.
-You are overclocking.
-You have an app preventing the phone from deep sleeping.
-You didn't do full charge cycles yet so the battery is not calibrated..

Mine lasts bout 18 hours.. So also theres a factor on how old the device is.. My battery backup is 1/2 of original so if ppl are experiencing this they should change their batteries .. U can find oit by display usage tym.. My battery dies after the display usage goes above 2 hours while on a normal battrery phone its 4 hours
Sent from my GT-I9003 using xda premium

shriomman said:
Mine lasts bout 18 hours.. So also theres a factor on how old the device is.. My battery backup is 1/2 of original so if ppl are experiencing this they should change their batteries .. U can find oit by display usage tym.. My battery dies after the display usage goes above 2 hours while on a normal battrery phone its 4 hours
Sent from my GT-I9003 using xda premium
Click to expand...
Click to collapse
That's true, just like laptop batteries, they degrade with time.
Also, i noticed that you need to recalibrate the battery by doing at least 2/3 full cycles without using the phone (Charge it 100%, let it drain until it shutdowns by itself 'don't use it for the best results', and do that 2 times, should calibrate perfectly now)..

Skander1998 said:
That's true, just like laptop batteries, they degrade with time.
Also, i noticed that you need to recalibrate the battery by doing at least 2/3 full cycles without using the phone (Charge it 100%, let it drain until it shutdowns by itself 'don't use it for the best results', and do that 2 times, should calibrate perfectly now)..
Click to expand...
Click to collapse
Calibrating shouldnt b done to much ill say.. Just do it once a new rom is installes thats irt to much of charging and drainin to 100-0 is nt gud for l-ion batteries . Its actually bad.. I read.. So since then i charge my battery after its at 20%
Sent from my GT-I9003 using xda premium

i have trouble using Battery calibrator. After doing the cycle i cant get the charging up to 100% only 99%.

shriomman said:
Calibrating shouldnt b done to much ill say.. Just do it once a new rom is installes thats irt to much of charging and drainin to 100-0 is nt gud for l-ion batteries . Its actually bad.. I read.. So since then i charge my battery after its at 20%
Sent from my GT-I9003 using xda premium
Click to expand...
Click to collapse
But you'll do it two times only, so it shouldn't harm the battery.
marshygeek said:
i have trouble using Battery calibrator. After doing the cycle i cant get the charging up to 100% only 99%.
Click to expand...
Click to collapse
Don't use apps, do it yourself, after calibrating start recharging as usual from the 10%-20% and not 0%.
Let's keep this related to kernel 3.x

Really nice news!
Enviado desde mi GT-I9003 usando Tapatalk 2

cant wait to see the result, hope they can make it soon

Look at this good news. Hillbeast compiled a kernel based on BCK. Check it out... I think it has linaro compiled if i am not wrong...

crazbanditz said:
Look at this good news. Hillbeast compiled a kernel based on BCK. Check it out... I think it has linaro compiled if i am not wrong...
Click to expand...
Click to collapse
Yes it is using Linaro.
Also what are peoples AnTuTu scores on this phone? I just ran it with my compiled BCK and it got 2312 (CPU: 496, GPU: 1007, RAM: 214, IO: 595). Good or bad? I don't have anything I can compare it against (at least not fairly...)

Its pretty bad cos cant use odin anymore...? For kernel 3.x

[DEV][TWRP/CWM/...] Backing up the boot (kernel/LNX) partition !

Hello folks,
it's me again (RaymanFX aka Chris Hesse) and I want to introduce you to a little, but important project.
​ My goal is to finally be able to backup the 'boot' partition of our device in CWM and TWRP or others !
​
How can we get to that ?
Well, I already have an exact plan on how to do it.
1. Step : examining the boot partition (LNX) size and offsets
2. Step : invoke a kernel hack to parse the partition layers to the system at runtime (WARNING : This will only work on a hack-enabled kernel) - I will provide one.
3. Step : re-enable 'boot' partition backup (in TWRP, e.g.) I will recompile TWRP with newest code when the time is right
Ok, so what do we have ?
1. To examine these partition layout sizes and offsets, we have to strip of the hex value of !ANDROID or ANDROID! of /dev/block/mmcblk0 using the dd command.
I already did this.
Here's how to do it :
Code:
iMac21:~ RaymanFX$ adb shell
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
~ # dd if=/dev/block/mmcblk0 of=/sdcard/20m.bin bs=1M count=20
20+0 records in
20+0 records out
20971520 bytes (20.0MB) copied, 1.271406 seconds, 15.7MB/s
~ # exit
iMac21:~ RaymanFX$ adb pull /sdcard/20m.bin /Users/RaymanFX/Desktop
2413 KB/s (20971520 bytes in 8.487s)
Then open a hex editor and search for the sring value 'ANDROID!' and copy that value.
Mine is :
Code:
0x37FFED
Now we have to convert this to get the sizes and offsets we need (I work together with Dees_Troy to resolve this).
-> To be fixed soon !
2. When we proceed, we need to invoke a kernel hack at compile time, so every old kernel needs to be recompiled.
-> I will provide a recompiled and hack-enabled harmony kernel soon
Code:
Here will be the required code fix; commit at my GitHub
3. And last but not least :
A new version of TWRP needs to be compiled to re-include the boot partition for the nandroid system, i will compile one with the newest updates once the previous steps are made.
As always, I need assistance to proceed faster with your help.
I can do everything on my own, but it will take time. What I need the most urgent is someone to convert the hex values to get the offset and size values.

One for me
The recompiled harmony kernel and information for kernel devs will be posted here.

Last one, open disscussion now !
NOTE : THIS IS A [DEV] THREAD, SO PLEASE DON'T CLUTTER IT WITH QUESTIONS THAT DON'T BELONG IN HERE. IF YOU WANT TO SUPPORT ME, HIT THE 'THANKS' BUTTON TO KEEP ME MOTIVATED !

Hmm, sounds intriguing. Why would we want to backup our boot partition exactly? Sorry, I just had to ask. Why wouldn't we be able to poll the partition via adb, or is this to make it possible via a GUI? Or are you talking about the boot loader? Argh, I'm confused...

hanthesolo said:
Hmm, sounds intriguing. Why would we want to backup our boot partition exactly? Sorry, I just had to ask. Why wouldn't we be able to poll the partition via adb, or is this to make it possible via a GUI? Or are you talking about the boot loader? Argh, I'm confused...
Click to expand...
Click to collapse
so we can back up kernel, each time we restore a rom from CWM it does not restore kernel so we have to reflash that.

hanthesolo said:
Hmm, sounds intriguing. Why would we want to backup our boot partition exactly? Sorry, I just had to ask. Why wouldn't we be able to poll the partition via adb, or is this to make it possible via a GUI? Or are you talking about the boot loader? Argh, I'm confused...
Click to expand...
Click to collapse
The 'boot' partition (LNX, in our case) stores the whole kernel and the ramdisk, combined as a boot image.
This means if I am successful, we can just backup the kernel in recovery along with the rom, like other android devices already do.
E.g. when you flash a new rom, but backed up the old one first, you have to flash a kernel compatible with the rom manually when going back to your backup as of now.
After my work has succeeded, you can just restore the old android, which restores the kernel automatically.

RaymanFX said:
The 'boot' partition (LNX, in our case) stores the whole kernel and the ramdisk, combined as a boot image.
This means if I am successful, we can just backup the kernel in recovery along with the rom, like other android devices already do.
E.g. when you flash a new rom, but backed up the old one first, you have to flash a kernel compatible with the rom manually when going back to your backup as of now.
After my work has succeeded, you can just restore the old android, which restores the kernel automatically.
Click to expand...
Click to collapse
Okay, I thought so, I just needed confirmation. Bad question #3: why can't we did the kernel partition, and restore it that way?

hanthesolo said:
Okay, I thought so, I just needed confirmation. Bad question #3: why can't we did the kernel partition, and restore it that way?
Click to expand...
Click to collapse
Ask this to ASUS !
Those guys gave us a crappy partition layout, meaning we only have /staging for flashing boot and recovery blobs, NO REAL PARTITIONS holding those files. -> UNITL NOW ! I examined the boot offset and size ...
Seems like the recovery ad boot partition share the same offsets and sizes .. will check this
EDIT : Progress : I have the offsets and sizes right at my hands !
See : My hex offset is 0x37ffed, I take this and convert it to decimal ()10 ... then I get 3669997, which fits our definitions perfectly (7chars).
Now, we have to divide this by the block layer size (512), we get 7167.962890625, which is ugly.
The second one has hex offset at 0x87ffe8, decimal at 8912872, decided by 512 makes 17407.953125

Very nice work, seems like more and more people are learning to dev.

RaymanFX said:
Ask this to ASUS !
Those guys gave us a crappy partition layout, meaning we only have /staging for flashing boot and recovery blobs, NO REAL PARTITIONS holding those files. -> UNITL NOW ! I examined the boot offset and size ...
Seems like the recovery ad boot partition share the same offsets and sizes .. will check this
EDIT : Progress : I have the offsets and sizes right at my hands !
See : My hex offset is 0x37ffed, I take this and convert it to decimal ()10 ... then I get 3669997, which fits our definitions perfectly (7chars).
Now, we have to divide this by the block layer size (512), we get 7167.962890625, which is ugly.
The second one has hex offset at 0x87ffe8, decimal at 8912872, decided by 512 makes 17407.953125
Click to expand...
Click to collapse
Oh, okay, ouch, this sounds like it is going to be a LOT if fun to do . I thought it would be possible because the uodater-script flashes kernels to mmcblk0p4, but I guess that was staging, not the actual kernel partition (this also explains why I got a fliesize if 500ish MB the other day when I dd'ed the partition). Good luck to you, and I will try to help the next time I am bored/have free time.

The important stuff is in the header (raw?) of mmcblk0, so it should be possible to just use dd.

K900 said:
The important stuff is in the header (raw?) of mmcblk0, so it should be possible to just use dd.
Click to expand...
Click to collapse
... so ?
Look at my first post, this is exactly what I did. Stripped off the first 20M and found the offsets. I am getting assistance from Dees_Troy and the TF300 devs to ensure everything is going the right way.

RaymanFX said:
... so ?
Look at my first post, this is exactly what I did. Stripped off the first 20M and found the offsets. I am getting assistance from Dees_Troy and the TF300 devs to ensure everything is going the right way.
Click to expand...
Click to collapse
What I mean is patching the kernel to make it a 'partition' is dangerous and can cause unexpected results, so dd and a modified recovery should be used instead.

K900 said:
What I mean is patching the kernel to make it a 'partition' is dangerous and can cause unexpected results, so dd and a modified recovery should be used instead.
Click to expand...
Click to collapse
Believe me, they can't be used. We need the kernel patch. The guys from tf300 tried anything, but using the kernel hack was the only way to make this possible.
And if (not possible in theory) the hack would cause problems, we can always flash a different one since the /staging-flash is not affected at all

RaymanFX said:
Believe me, they can't be used. We need the kernel patch. The guys from tf300 tried anything, but using the kernel hack was the only way to make this possible.
And if (not possible in theory) the hack would cause problems, we can always flash a different one since the /staging-flash is not affected at all
Click to expand...
Click to collapse
There should be other solutions that don't involve uber ugly kernel hacks. I'll see if I can get more info since I have some docs regarding the boot process on generic Tegra boards and reusing same methods (likely bypassing ASUS bootloaders altogether) should be possible, at least now that we have nvflash access for all.

Hey Rayman, any word on this getting up and going? It will kick tail if you do. No more multiple zips then which means more space for me.

According to my research with others in the #asus-transformer channel on Freenode, the correct values are 0x380000 and 0x880000
380000 to decimal becomes: 3670016
3670016 / 512 = 7168 so 7168 is your first offset
880000 to decimal becomes: 8912896
8912896 / 512 = 17408 so 17408 is your second offset
The difference between the 2 values is hex 500000, decimal 5242880.
5242880 / 512 = 10240 which is your size for both.
Of course, after you build a kernel with the correct source and offsets, you'll want to dd dump the partitions and verify with a hex editor that you're getting the right stuff. Both partitions should start with "ANDROID!". You'll also want to unpack the contents of the dd images with unpackbootimg or something and determine which one is recovery and which one is boot. Most likely the first one is recovery.
Technically some of the other people are right. You can probably use dd with the right seek and size values to flash and dump the partitions without modifying the kernel, but modifying the kernel makes for a cleaner, simpler setup. We've used the kernel approach on the TF201, TF300T, and TF700T with much success.
Hope that helps.

Dees_Troy said:
According to my research with others in the #asus-transformer channel on Freenode, the correct values are 0x380000 and 0x880000
380000 to decimal becomes: 3670016
3670016 / 512 = 7168 so 7168 is your first offset
880000 to decimal becomes: 8912896
8912896 / 512 = 17408 so 17408 is your second offset
The difference between the 2 values is hex 500000, decimal 5242880.
5242880 / 512 = 10240 which is your size for both.
Of course, after you build a kernel with the correct source and offsets, you'll want to dd dump the partitions and verify with a hex editor that you're getting the right stuff. Both partitions should start with "ANDROID!". You'll also want to unpack the contents of the dd images with unpackbootimg or something and determine which one is recovery and which one is boot. Most likely the first one is recovery.
Technically some of the other people are right. You can probably use dd with the right seek and size values to flash and dump the partitions without modifying the kernel, but modifying the kernel makes for a cleaner, simpler setup. We've used the kernel approach on the TF201, TF300T, and TF700T with much success.
Hope that helps.
Click to expand...
Click to collapse
From my research
Code:
Position 3670016 / 512 = 7168
Position 8912896 / 512 = 17408
Diff
5242880
10240
From nvflash flash.cfg
SOS Size 5242880 / 512 = 10240
LNX Size 8388608 / 512 = 16384
Also, I already have a kernel compiled. I'll test later.

Just thinking about this thing and wondering about the linux-based (or are they also based on other architectures?) blob tools as a possible workaround? Ignore this if it seems silly. I haven't thought about this sort of thing for a long time and not at all on the transformer.
-
When any of the many kernel/ROM installer scripts take off and do their thing, they use the compiled (usually for linux, but some sort of combo binary and script) blob tools , I thought from Rayman as well (but it's been awhile since I've played with the source and the tools themselves.
Is there any reason why an android version of those couldn't be built and used inside either cwm or tw* to perform both the backup and retrieval of the kernel? I realize it would have to churn out an installer type script somewhere in the backup directory and run it upon restore, but would something like this be one of the multiple possible solutions? I'm guessing there is some obvious reason I've not looked into yet, like a dependency upon some other API or utility that is in a full linux system, but not in an android OS.. (but I don't know).
I suppose the good news of this would be that numbers tied to the partition wouldn't be of much importance since blobbing works OK without them, but there might also be a down side to adding a completely different type of backup/restore paradigm just for the kernel to a nice little piece of code (cwm/tw*) that works for everything else.

hachamacha said:
Just thinking about this thing and wondering about the linux-based (or are they also based on other architectures?) blob tools as a possible workaround? Ignore this if it seems silly. I haven't thought about this sort of thing for a long time and not at all on the transformer.
-
When any of the many kernel/ROM installer scripts take off and do their thing, they use the compiled (usually for linux, but some sort of combo binary and script) blob tools , I thought from Rayman as well (but it's been awhile since I've played with the source and the tools themselves.
Is there any reason why an android version of those couldn't be built and used inside either cwm or tw* to perform both the backup and retrieval of the kernel? I realize it would have to churn out an installer type script somewhere in the backup directory and run it upon restore, but would something like this be one of the multiple possible solutions? I'm guessing there is some obvious reason I've not looked into yet, like a dependency upon some other API or utility that is in a full linux system, but not in an android OS.. (but I don't know).
I suppose the good news of this would be that numbers tied to the partition wouldn't be of much importance since blobbing works OK without them, but there might also be a down side to adding a completely different type of backup/restore paradigm just for the kernel to a nice little piece of code (cwm/tw*) that works for everything else.
Click to expand...
Click to collapse
That would be an option as well I suppose. Take the image and call blobpack and build a blob to be flashed on reboot. Although, if we could 'dd' it cleanly without causing issues with other devices, that would be an ideal solution. Until then, this kernel change will work.

[Q] [HELP] Custom MTD partitioning for RK2918

Hi guys.
Several months ago, I have bought a rk2918 based tablet and succesfully rooted it as you can see in this thread. I haven´t managed to take the time and have more fun with this tablet until today, when I decided to tweak it a bit. So, I´m facing a bit of a problem and don´t know how to solve it. I wan´t to create a custom partition layout, in other words - I want to increase data and system partitions on this tablet. So if anybody understands mtd partitioning I would be grateful for any help. So here´s the current partition layout:
Code:
0[email protected](misc),
[email protected](kernel),
[email protected](boot),
[email protected](recovery),
[email protected](backup),
[email protected](cache), 112,4 MB
[email protected](userdata), 504 MB
[email protected](kpanic),
[email protected](system) 247 MB,
[email protected](user) 2.58 GB
So, I want to decrease "user" partition for 1024 MB, increase "userdata" partition for 950 MB and increase "system" partition for 74 MB. If someone understands how to do it, I would really appreciate it!

Anybody? I´m just refreshing this thread so people can notice it..

Root protab25
Sirrocco, could you make a root rights on this rom: Firmware Update TAB-PROTAB25 model 2.2_2.3 NOT for other versions.zip 179 MB
Please go to the link itself, I was a novice user can not post URL downloads.pointofview-online.com

The format is [email protected]
so if you want to increase size of userdata by 950MB you need to add 950×2048 which is in hexa 1DB000 to size of [email protected](userdata) which is
[email protected](userdata)
add same value to position of all following partitions (kpanic, system, user).
last partition is specified only by starting position and uses rest of memory so you don't need to worry about it's size
[email protected](user)

Ficik said:
The format is [email protected]
so if you want to increase size of userdata by 950MB you need to add 950×2048 which is in hexa 1DB000 to size of [email protected](userdata) which is
[email protected](userdata)
add same value to position of all following partitions (kpanic, system, user).
last partition is specified only by starting position and uses rest of memory so you don't need to worry about it's size
[email protected](user)
Click to expand...
Click to collapse
Omg, thank you man! Cheers! :highfive:

| bml0!c | dump bml0!c = complete oneNAND backup of SGY phone in one piece [research]

hi guYs !
on SGY phone, all of internal storage can be hexdumped (dd'ed) using this block device:
/dev/block/bml0!c
for details please read up these:
http://www.linux-mtd.infradead.org/doc/onenand.html
http://forum.xda-developers.com/showthread.php?t=801223 untagged thread on RFS; many document links ! good research !
http://forum.xda-developers.com/showthread.php?t=1543519
http://forum.xda-developers.com/showthread.php?t=1998471
http://forum.xda-developers.com/showthread.php?t=1818321
find attached the specs of SGY NAND-memory chip "oneNAND".
Linux-based NAND Flash software solution, offering higher performance and cost effectiveness for next-generation mobile phones. Samsung's Linux NAND Flash memory software allows the NAND Flash memory to store code as well as data. By eliminating the need for NOR Flash memory and supporting the Linux operating system with a demand-paging function, Samsung can lower overall costs and reduce space requirements in mobile handhelds.
Samsung's Linux file system, Robust File System (RFS), also offers greater data preservation capabilities in case of power disruption as well as wear-leveling for higher reliability. To address the problem of data loss from corrupted file allocation tables (FAT), Samsung's Linux-based NAND Flash memory solution also supports Transactional FAT for external memory cards. Compared to the conventional JFFS2 and YAFFS open file systems, Samsung's Linux file system enhances the NAND Flash write-speed up ten and four times , respectively.
This Flash memory solution is also available with Samsung's OneNAND (tm) Flash memory, which boasts a faster read speed compared to the conventional NAND Flash. With its advanced multi-tasking function, Linux will further accelerate the adoption of NAND Flash in next-generation mobile phones.
Importantly, as Samsung's new Linux NAND Flash memory software, RFS has completed verification in the Linux kernel 2.4.20-based Montavista Linux environment, Samsung's NAND Flash solution addresses the diverse needs of system developers for advanced performance, high reliability, shortened development time, asf.
with linux-mtd, SGY users can easily have "mobile ODIN" as well as "heimdall" open source flashing software, beause open sourced "mtd-linux" supports the SGY phones's memory electrical chip component named "oneNAND" !
this research thread aims at dissussing "mobile ODIN" using mtd-linux.
http://git.kernel.org/?p=linux/kern...ff;h=861fae1818db2ef09e6f3a836816fb1c2c402666
on oneNAND kernel support http://git.kernel.org/?p=linux/kern...c;hb=861fae1818db2ef09e6f3a836816fb1c2c402666 kernel source

mtd kernel params
http://git.kernel.org/?p=linux/kern...it;h=5988af2319781bc8e0ce418affec4e09cfa77907
onenand kernel support
MTD is the standard Linux way of accessing flash.
Samsung (maybe) says they have some new kind of OneNAND flash memory for which MTD is inappropriate, and for that they provide BML.
BML is a low-level interface.
On top of BML they provide STL which is slightly less low-level but doesn't seem to give any information about the boot partitions, only the filesystem ones.
RFS is the filesystem (an optimized journaling VFAT) that runs on top of STL.
MTD_Partition= [MTD] 1375 Format: <name>,<region-number>,<size>,<offset>
1376
1377 MTD_Region= [MTD] Format:
1378 <name>,<region-number>[,<base>,<size>,<buswidth>,<altbuswidth>]
1379
1380 mtdparts= [MTD]
1381 See drivers/mtd/cmdlinepart.c.
1382
1383 onenand.bdry= [HW,MTD] Flex-OneNAND Boundary Configuration
1384
1385 Format: [die0_boundary][,die0_lock][,die1_boundary][,die1_lock]
1386
1387 boundary - index of last SLC block on Flex-OneNAND.
1388 The remaining blocks are configured as MLC blocks.
1389 lock - Configure if Flex-OneNAND boundary should be locked.
1390 Once locked, the boundary cannot be changed.
1391 1 indicates lock status, 0 indicates unlock status.
1392
1393 mtdset= [ARM]
1394 ARM/S3C2412 JIVE boot control
1395
1396 See arch/arm/mach-s3c2412/mach-jive.c

bml1 132kB - "primary boot loader"
bml2 1284kB - "secondary boot loader" - loads the kernel and also supports a "download mode" in which it can talk to a PC using Odin protocol via a virtual serial port (USB). Should be a plausible last resort in most bricking scenarios.
http://hogeruda.se/wordpress/tmp/odin3-1.85-help

this could be helpful., sooner sgy will be support mobile odin.. thank you for this..
Sent from my Android System using Busybox Command.

I thought the SGY was on ReiserFS
Now I have to learn it really is RobustFS

releases prior to Heimdall 1.4 alpha I could not get to work with SGY. I tried everything under VISTA.
maybe Heimdall 1.4 dumps the SGY pit-file.
###############################
Linux would use : mtd, UBI, UBIfs
Samsung uses: bml, stl and RFS instead
on the physical oneNAND chip.

Hello, i'm not experienced with filesystems, however, i'm trying to figure something out about /dev/bml5 (BcmCP.img)
So as far as I know, this file can be mounted (because it's a .img file)
Would the filesystem be R(obust)FS?
For now i'm just trying to extract it to its contents so I can examine them

Mount as loop device and chroot into it.

I have very little experience in file systems :/
if we had more 1 mb on Partition kernel + ramdisk(only 5242880 bytes we have ) referency https://docs.google.com/spreadsheet/ccc?key=0Arilp8uJromLdHdrdGpiZ2FSN3daRzRQMkIxR0pCZXc#gid=0(maybe modifications in totoro.pit :/ )
I could easily build a cwm 6.x for us :/

Why not put cwm on sd card ?

Btw, does anyone know of the availability of the LinuStoreIII (FSR) drivers version 1.2.1? The only leaked source code I could find was https://github.com/supercurio/samsung_fsr, but it is version 1.2.0 and the SGY is on 1.2.1
I want to use a new tool chain and upgrade my kernel to 2.6.35.14 …
Maroc-OS somehow managed to build the FSR modules but I just don't get how. Any ideas?

check http://forum.xda-developers.com/showthread.php?t=801223
for LinuStore III

http://de.slideshare.net/search/slideshow?searchfrom=header&q=onenand
many docs there which otherwise disappeared: dead links on #1 reference post on I9000

guYs, u gotta check this out :
battery brutus kills SGY users ! http://www.youtube.com/watch?v=w6DqwJgxc_k
video by Samsung.
http://www.samsung.com/global/business/semiconductor/minisite/memory/campaign.html#fiona_freeze