yashsingh1/xdaforums huggingface dataset:
[G1 Android Development] lbcoder:
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.
[G1 Android Development] zim2dive:
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)

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
[G1 Android Development] ezterry:
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
[G1 Android Development] lbcoder:
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.
[G1 Android Development] Sik-1:
Agreed +10 for lbcoder, but seriously, since u started scripting, I haven't seen any help and have a rom moving the way u have, I say u join up with king and have some friendly comp with cyan bcuz he got a lil team with him, lol
[G1 Android Development] Firerat:
rofl

why don't you suggest that to King

::chuckle::

I have said for a long time that he is clueless, he has created nothing and taken everything.
[G1 Android Development] Sik-1:
I def will, cuz everybody copying cyan and yet they chasing king's tail, and so far he has giving credit to those who deserve
[G1 Android Development] Firerat:
<insert facepalm>

don't... it was a joke he won't take kindly to it ;)
[G1 Android Development] Sik-1:
lol ur hilarious
[G1 Android Development] Firerat:
created a new thread

http://xdaforums.com/showthread.php?p=7061484#post7061484
[G1 Android Development] ezterry:
So proof of concept flashing hboot directly from recovery works:

using Eng2:

Tidus:recovery ezterry$ fastboot -c "mtdparts=msm_nand:256k@0x24C0000(misc),5120k@0x26C0000(recover),2560k@0x2BC0000(boot),92160k@0x2E40000(system),5120k@0x8840000(cache),768k@0x2400000(hboot)" boot recovery-RA-dream-v1.6.2-green.img
downloading 'boot.img'... OKAY

Then adb push 1.33.2005 hboot image to the phone and 'flash_image hboot hboot.img'

reboot bootloader happily entered the 1.33.2005 SPL w/ 1.x radio without brick..

obviously risky to do it manually like this

currently the only check is the checksum in the "dev" signed update.zip that anyone can create.. So if you just adjusted the function of recovery to flash directly the same checks are still in place.

however it may be wise to make a special flash app rather than flash_image (using the same underlying mtd calls) to help ensure erases/flashes are cleaner..

I mention this because flash_image seems to fail to overwrite is certain situations.. and we have a 4 block SPL with only 2 spare blocks

There is a good reason to wish to flash a SPL with all the engineering functionality. however in general no recover need not flash hboot..

What you are looking for is similar to the rogers rooting procedure where part of rooting is the installation of 1.33.2005.. and then you never need to touch the boot loader again.

In theory
[G1 Android Development] zelipukin:
BT pairing

I do not use BT often so just discovered no BT connection.

have done above mentioned changes in 04modules

and, yes, I can turn BT on and off now and the phone sees

my PC and headset and vv but when I try to pair my phone with PC or HS

"Cannot establish communication with..." message appears

logcat:

V/BluetoothEventRedirector( 1604): Received ndroid.bluetooth.device.action.BOND_STATE_CHANGED

E/bluetoothd( 1762): bt_io_connect: socket(RAW, L2CAP): Protocol not supported (93)

V/BluetoothEventRedirector( 1604): Received android.bluetooth.device.action.BOND_STATE_CHANGED

I know its kinda outdated but my phone in its current configuration

runs so great as never before. therefore I dont want to make any

major changes. I'm completely satisfied with my ancient G1, thanks to you guys.

and BT is not an issue if in case to make it working I need to wipe and reflash - not now

Thank you again!

G1

2.22.19.261

1.7.0

114/5 partitions

CM5.0.8 DS

FR-2634-MPH-s90c5d114_S

8GB cl.6 32/512/
[G1 Android Development] lbcoder:
You know, funny thing -- I've been having the same trouble with BT.

It *was* working fully under this scheme, but something changed/broke. I have been suspicious of the "weird text in console" bug/patch since the bluetooth failure seemed to start at about the same time as I applied that patch, however, I haven't really looked at it since -- too busy laying floor tiles in my basement.

You wouldn't, by any chance, be running the console-text patch, are you?
[G1 Android Development] Firerat:
that would make sense

some of the 'newer bits' were left out of the font fix patch

I've seen mention of it in the issues list
[G1 Android Development] Firerat:
btw

Linux localhost 2.6.34-cyanogenmod #4 PREEMPT Tue Jun 29 22:13:15 EDT 2010 armv6l GNU/Linux

from CM6 nightly is booting fine on my G1, just flashed 1.33.2003

( I flashed 1.33.2005 and confirmed that 5.0.8F's kernel was booting fine, where it wasn't on 0.95.3000 )
[G1 Android Development] lbcoder:
Now here's a question for you: does 508F's kernel boot on 1.33.2003?
[G1 Android Development] Firerat:
literally just flashed 1.33.2003

but yeah, something I want to try

Edit:

yeap

Linux localhost 2.6.34-cyanogenmod #1 PREEMPT Sat Jun 19 06:28:29 EDT 2010 armv6l GNU/Linux

is booting fine for me with 1.33.2003 spl
[G1 Android Development] zelipukin:
since I new about console/eReaders text issue I have applied this patch right after cm508 flashing
[G1 Android Development] lbcoder:
I'm getting worried about a possibility of bricking.

Don't everyone get all excited, its not related to this procedure -- what I'm thinking is much more GENERAL..... actually related to CM kernel (though not as a form of BLAME -- just as an observation, which is a GOOD thing since I am observing it BEFORE it can damage anything).

This concern is related to Firerat's observations regarding booting CM5.0.8 kernel in conjunction with 0.95.3000 SPL, plus this: http://xdaforums.com/showpost.php?p=7063746&postcount=18

My worry is that IF such a kernel is built in to a RECOVERY, then there could be a new round of bricks, EVEN IF the radio and SPL match up perfectly.

The events to create such a brick are as follows;

1) Someone creates a recovery, tests on some 1.33 SPL -- works, but without knowing it, bootloops on 0.95.

2) Someone with a 0.95 installs this recovery from a running system.

3) This person goes to boot to the recovery by issuing a "reboot recovery", which sets the command field of the MISC partition to boot-recovery and reboots.

Recipe for disaster, no?

Because when the boot-recovery command is set, the device DOES NOT RESPOND to boot-time signals, i.e. to go to fastboot. At the same time, it will fail to CLEAR the boot-recovery command since it crashes/loops.

The other problem is that sensible testing procedures don't work since by Firerat's observations, fastboot boot is able to boot the kernel where flash-boot is NOT.

Which makes the following the only working testing procedure for 0.95.x000 SPL:

1) fastboot boot it. If that works, go on to next step, else back to drawing board.

2) flash it and then DO NOT reboot-recovery!!! do normal boot and hold the HOME button. If THAT works, you're good, if not, don't forget to write another known good recovery image.

@EZTERRY (if you read this): You are rigged up to do the jtag experiments. We need more information about the bricking process -- specifically, the link above shows an interesting thing -- exec sh permission denied, followed by boot loop. What has become clear is that ALL THREE of the RADIO, SPL, and KERNEL have to "work together". What we need to do is track down the following; WHY does a recovery image NOT BOOT with a bad radio/SPL pair? WHY does 'exec sh' fail? Is it POSSIBLE to make a "safe" recovery that can clear the MISC command field BEFORE bootloop or freeze? Obviously, in the link above, *something* is alive, is the same true for a mismatched radio/spl? Reasoning is that IF something is alive enough in the brick to clear the command field, then when it boot loops, it will be able to fastboot.

So I guess the question is IF we put something into the kernel itself to clear the command field, will it be able to stop bricks from happening?

@FIRERAT:

I am thinking that it MIGHT NOT BE A GOOD IDEA to have a recovery auto-patcher. If something DOES go wrong, it may be possible to brick from it. In general, I think that anything that can possibly cause a recovery boot-loop has the potential to create a brick.
[G1 Android Development] lbcoder:
$5 says that if you revert it, bluetooth will work again. Unfortunately though, you're between a rock and a hard place.
[G1 Android Development] Firerat:
Just about to start a darts match

But yeah I hear you

By default recovery reboots to boot,

Ilve trashed recovery a few times, one was trying to boot 5.0.8's kernel from it

You can always get back

There is no rerason why recoveries need to use new kernels ( at least I see no need at the moment, besides mtd kmods if we take things further )

I can buildmany checks into the script, flash_image gives a basic exit code, and futher info to logvcat (need to add logcat bins to get that out , - I think )

My g1 is eol now,I'll probably get a desier ( want keyb tho :( )

I can put my g1 in harms way ( I have been the past few days, but I did know from past experience how to fix trashed system / data partitions, lol nevery be clever and flash_image system <path>/system.img, it doesn't work ;) )

As I see it the worst that can happen is we can'treflash recovery if we don't have fastboot, so have to nbh and re-root

The only time recovery has failed on me is flashing from cm5.0.8t5+, and flashing cm5.0.8 to it

Oh and junk, but that was deliberate , and a dd if=sys.... which was silly.

But yeah, I can build in checks
[G1 Android Development] lbcoder:
You missed the point. This isn't about TRASHING recovery, its about the *possibility* of having an incompatible kernel in recovery combined with a command field with "boot-recovery". In this event, it won't get to the point of clearing "boot-recovery", so it WON'T go back to a normal boot -- reboot and it'll try to go straight back into recovery.

And yes, I realize that there may be no reason *yet* to update the kernel in recovery. From my observations, this has never stopped everyone from TRYING.

Oh, and don't be trashing your phone.... crazy experiments like this should be left up to those with a jtag test rig... if ezterry sees this stuff, maybe he'll help out with this experiment.

If you can hold off a few months... the "HTC VISION" may be what you're looking for as a replacement.
[G1 Android Development] Firerat:
@lbcoder

Yeah got you,

I can probably 'turn off' the ability to reboot to recovery , within the running recoverey via the script

Not sure I can stop adb from doing it

Actually I can just disable adb, so only reboot option is standard reboot
[G1 Android Development] lbcoder:
I don't think there is much risk there. There are two potential problems that I see;

1) flash recovery image from within running system and then "reboot recovery",

2) can happen just like a deathspl brick -- from a working 1.33 SPL, flash a 0.95 SPL with a recovery image that happens to be incompatible with 0.95.

Now what we know is that even with a deathspl brick, it isn't *completely* dead. The question is this: at the earliest possible spot to be able to clear the command field, is it still LIVE? If the answer is YES, then we need to modify whatever component is still LIVE to actually go clear the command field.
[G1 Android Development] ezterry:
Just made a clean install with:

# cat /sdcard/mtdpartmap.txt
91 2

made sure it booted and made a nandroid backup

a) Then set up the radio+spl for the test

b) wipe (fastboot erase system -w;fastboot erase boot)

c) restore nandroid backup

d) shutdown

e) boot

All booted into android in this test:

androidboot.bootloader=1.33.2003
androidboot.baseband=1.22.12.29

androidboot.bootloader=0.95.3000
androidboot.baseband=1.22.12.29

androidboot.bootloader=1.33.2003
androidboot.baseband=2.22.23.02

androidboot.bootloader=0.95.3000
androidboot.baseband=2.22.23.02

serial boot output:

http://android.pastebin.com/MjBXDn0g

However I did in some of my other experiments see the "exec '/system/bin/sh' failed: No such file or directory (2) -" error with 2.22.23.02/0.95.3000

I'm hoping the issue is just a failure to mount /system .. if that is the case recovery would not brick..but I think some more experiments are needed.
[G1 Android Development] zelipukin:
sorry, if I'm out of topic

but does this piece of code make any sense

if [ "`getprop persist.net.ipv6`" = "1" ]; then

MODULES="$MODULES ipv6"

fi

since ipv6 is optional in 508DS and never returns "1" untill

you custom enable it somewhere via setprop or somehow?

but it does not affect on the rest of the code? or it does?

also if fontfix patch may corrupt BT and thousands have applied it

why nobody cries about missing BT? well, except me.

but I'm not crying. just curious:confused:

G1

2.22.19.261

1.7.0

CM5.0.8

FontFix patch

FR-2634-MPH-s90c5d114_S

8GB cl.6 32swap/512ext4/

114/5
[G1 Android Development] Firerat:
we can use the kernel cmdline to 'get round' assert checks

for instance, CM6 'weeds out' NoneDanger

but

fastboot -c "androidboot.bootloader=1.33.2005 mtdparts=msm_nand:256k@0x24C0000(misc),5120k@0x26C0000(recovery),2560k@0x2BC0000(boot),87040k@0x2E40000(system),2048k@0x8340000(cache),-@0x8540000(userdata)" boot ~/Downloads/recovery-RA-dream-v1.7.0.img

( NB the mtdparts is specific to my layout, use your own ;) )

the above is academic if you use clockwork, as it gives you the option to dodge assert checks

edit: which doesn't seem to work in cwr 2.0.2.0

this is what /proc/cmdline looks like

~ # cat /proc/cmdline

board_trout.disable_uart3=0 board_trout.usb_h2w_sw=0 board_trout.disable_sdcard=0 smisize=64 androidboot.baseband=2.22.23.02 androidboot.cid=T-MOB005 androidboot.carrier=TMUK androidboot.keycaps=qwerty androidboot.mode=normal androidboot.serialno=<some serial, got paranoid ;) > androidboot.bootloader=1.33.2003 androidboot.bootloader=1.33.2005 mtdparts=msm_nand:256k@0x24C0000(misc),5120k@0x26C0000(recovery),2560k@0x2BC0000(boot),87040k@0x2E40000(system),2048k@0x8340000(cache),-@0x8540000(userdata)

I have two androidboot.bootloaders, lol, but more importantly it passes assert checks, as far as the updater-script goes, it thinks I have DangerSPL
[G1 Android Development] lbcoder:
What kernel are you booting?

It would be nice to see the combination of 0.95 SPL + 5.0.8 kernel (unless you did that and it is now working for some reason...) which seems to fail.

The differences in the bootup from 0.95 to 1.33 are striking...

Note the header, kernel, and ramdisk load address, target, and sizes shown for the 0.95, but not for the 1.33.

I definitely would like to see another kernel booted on both of them, I am thinking that somehow there may be a hard limit placed on the size of the kernel for 0.95 (but not for 1.33, or possibly higher and just not output) -- which might be 0x509BD000-0x507C0800 = 0x1FC800.... which would explain the failure to boot the 508F kernel on 0.95

Just have to wonder if these addresses are hardcoded or not....
[G1 Android Development] lbcoder:
That just controls whether or not you should be wasting memory by loading the ipv6 module depending on whether the ipv6 property is set.
[G1 Android Development] lbcoder:
To reply to myself....

My HYPOTHESIS:

The load addresses are hard coded. If the kernel size exceeds 1FC800, then the tail end of the kernel runs into the ramdisk address and gets overwritten by the start of the ramdisk, thus it fails to boot.
[G1 Android Development] ezterry:
Yes just the stock cm 5.0.8 kernel patched with firefrat's script.

So it worked for me.. but not on every flash.. thus I think something else was wrong (badly formatted system or something)

I think address shown/not shown is just the debug statements included or not.. there is obviously significant changes in the boatloader codebase.
[G1 Android Development] Firerat:
I was having problems with it before I was patching with mtdpart

everything else was fine, I could get 5.0.8 to boot up via fastboot, it would only fail if I flashed it to boot or recovery ( either via recovery or via fastboot )

when I reduced the zImage size ( by setting the bt as modules ) it worked fine when flashed

I only really had one independent confirmation..

at least one other person was getting a failed boot with no adb/logcat, which was resolved when the reduced size zImage was used

Since then I have booted 5.0.8's kernel fine with 1.33.2005 and ..2003

I haven't retried 0.95.3000 yet
[G1 Android Development] Firerat:
just thought I would share where I got upto with mtd as kernel modules

couple of weeks ago I got the mtd compiled as modules

( you need to apply this diff to get msm_nand to compile )

--- orig/arch/arm/mach-msm/dma.c 2009-12-30 03:25:36.000000000 +0000
+++ new/arch/arm/mach-msm/dma.c	2010-07-30 09:45:47.000000000 +0100
@@ -141,7 +141,6 @@
PRINT_FLOW("dmov_exec_cmdptr(%d, %x) done\n", id, cmdptr);
return 0;
}
+EXPORT_SYMBOL(msm_dmov_exec_cmd);

static irqreturn_t msm_datamover_irq_handler(int irq, void *dev_id)

it _kind of_ works, but for some reason when as modules they won't use the Command line partition table parsing'.

you don't get the option when configuring the kernel, but even after modifying Kconfig to get the option it just isn't supported.

guess I'll have to dig deeper and figure out why its not working when as modules.
[G1 Android Development] ktmdms:
Playing with this, I was trying to use the MTD-helper.sh script to make a boot image file with 100Mb system, 5Mb cache, and the rest data. I did the following to capture the latest bootimg info:

cat /dev/mnt/mnt2 > /sdcard/boot_old.img

Then I used adb to get that onto my linux machine and ran the MTD-helper.sh:

MTD-helper.sh 100 5 boot_old.img

This created a new boot image file for me. I then did the following to try to apply the boot image to my G1:

adb push ./MPH-s100c5-boot_old.img /sdcard/new_boot.img

adb shell

# cat /dev/zero > /dev/mtd/mtd2

# flash_image boot /sdcard/new_boot.img

and rebooted. But the G1 never got past the initial T-Mobile G1 screen and what I saw logcat were a bunch of messages saying "data/misc/keystore no such file" and it looked like /data was no longer a mounted partition, just a directory. I managed to recover to the 6.0.0 released zip file and my phone is back working again, I'm just trying to figure out what I did wrong/where I missed a step.

Thanks.

Kevin
[G1 Android Development] lbcoder:
You can't just remap your partitions!

You have data that is aligned to the starts of your OLD partitions. You need to realign the data in those partitions by FORMATTING THEM *while* the new partition layout is active.

This is why the procedure involves first booting into recovery with a custom commandline, then formatting, then installing a modified boot image.

FYI: I suggest reading Firerat's thread. He has developed some real nice scripts for doing exactly what you are trying to do.
[G1 Android Development] jayb222:
I want to revert back to how it was before I flashed the custom partitions. Is there an easy way to do this? I've had nothing but problem with cache and flashing roms after doing this.
[G1 Android Development] AndDiSa:
Reflash a non-patched recovery image, wipe and you are fine. More details in Firerat's custom mtd thread (see link in my signature).
[G1 Android Development] jayb222:
I flashed Amon RA-Dream-v1.7.0: dev/block/mtdblock4 says 30.0M

That means all is good? Because when running bart restore I get: Cache error no space left on device and it says 100% full. Is there a fix?
[G1 Android Development] lbcoder:
This is NOT the place to be asking about this. Go away and find a more suitable place to ask.

I suggest Q&A section.
[G1 Android Development] mdneilson:
fastboot erase cache
[G1 Android Development] jayb222:
My problem was in part due to the custom partitions I flash from this very post so I asked a question here. Thanks to the thoughtful post. As for the other, I'll ...go away now. Sorry I derailed this thread and got way off topic. You might as well close this since nobody will ever find any useful information in it due to my spammy post. Hmmm, next time I'll write "good job" or "flashing now" over and over. Some people can be so rude. You should try and be human sometimes and politely suggest I go to Q&A. I would of kindly done so.

Edit - and thank you AndDiSa. I see that now.
[G1 Android Development] AndDiSa:
For sure Firerat's custom mtd thread is a better place for asking. This thead here is more theory and background ;)
[G1 Android Development] Firerat:
type less and read more