[Samsung Galaxy Mini] Doc_cheilvenerdi.org:
Beta Testing...

How I Test all the boot images before sharing them

When I power on the phone the hardware bootstrap passing soon after the control to the (using PC terminology) BIOS (Basic Input OutPut System)... a sort of mini system used to poweron all the peripherals inside and related to the phone... (In my Galaxy Next - briefly - I find something similar in the code sequence mibib-qcsbl-oemsbl-amss-arm11boot)...

...Immediately after, the BIOS loads into memory the Kernel in a fixed position and an initial ramdisk (in a fixed position too) and leave control to the kernel...

...the kernel setup the ramdisk and use the second mini system inside to complete the boot stage...

...Finally the kernel - using commands in the ramdisk - give control to the real system - GingerBread.

Actually the Bios releases control to the kernel calling a routine starting always from a fixed point hardcoded in itself and the Kernel launch the system (wherever it is) looking in the init files inside the ramdsik...

While slightly upgrading GingerBread from 2.3.0 to 2.3.* the mid part of the full boot sequence (kernel + ramdisk) need only two things to work properly:

Kernel compiled with the first assembly code starting from the fixed position hardcoded in the Bios

init files in the ramdisk showing where the filesystem and its data are...

Finally: All boot.img of GingerBread flavours meet these prerequisites... so I can easily use anyone of them with my system (or any other minor version of Ginger) while my BIOS call the kernel and it is in the right place and the init files exit to the filesystem where it really is...

I simply flash one of the shared boot images and test it three times:

power on with micorSD outside (system boot as usual)

power on with microSD inside and /data empty (the system fill it with all what is needed)

power on with microSD already full of apps, userdata and cache

I check mount points, SD read ahead, browse something on Internet, Market...

...and Finally I feel comfortable with the image cooked...

...I can share It!

Why didn't I said that you can use any of the shared boot images

If I simply call the boot image (for example)

CODE_S5570DOC01_boot.tar.md5

probably several end users (not heavy skilled with Linux, boot, Android, etc...) could be scared to use it...

... so I decided to provide an image for any of the "most wanted versions" now on the network using the attached kernel (anyway slightly different each other) with the same name of the Stock Version...

How I handle Errors reported from end users

With my Wind boot.image first, and then with the JVTK1 one, I did what follows:

First Test

I exported my contacts to SD twice (about 2 minutes every time)

I imported it four times from SD without overwriting existing ones (about 1 minute to 2 minute at last) growing it to 400 entries

I exported and Imported them again (2 +2 minutes)

Test made with both the boot images - same result

Second Test

I own Titanium Backup PRO so I performed a backup of 98 apps (about 200Mb mixed from /system and from outside /data) to SD (4-5 minutes)

I repeated 3 times forcing the full operation (always about 5 minutes)

I Verified the backups towards original apps (3-4 minutes) (Found 2 errors related to WiFi in both boot images)

I restored 25 apps (this time only the ones stored on the outside /data - left untouched /system); I needed 10-12 minutes to reinstall them while dr web light antivirus was underneath scanning them. (Market crashed once in JKVT1 boot image)

Third Test

Called friends by Phone,

Sent some SMS to them,

Whatsapped them too,

Browsed xda-developers forum with Opera Mobile and Tapatalk.

Fourth Test

Don't do it!

I started "via emulator terminal" to dump a 100Mb wide file copying from /dev/zero...

while writing to SD I removed it crashing the system...

All fine after reboot... but (I'll soon post about what I'm saying) I suggest to use tools like fsck for errors out of journals...

Last Test

I own a Very old SD (1Gb) at the end of its lifecycle...

Every time I use it, bad blocks appear... timing readouts... freezing PC ports where connected...

...so I consider it a very bad hardware...

...but very useful for extreme tests of hardware/software endurance...

I made this test only with JVKT1 anyway...

I prepared the 2 partitions in it on my Linux PC (system froze twice then I was able to write partion table and format them)...

...Power On the phone with SD inside...

...adb shell and ddms connected to follow the de-wipe operation from PC..

...needed 40 minutes to complete it...

...frustrating...

...the System ended up and running anyway...

Conclusions

I think that the problem noticed should be investigated outside the boot stage of Ginger JVKT1 image...

How I cook the boot images

The images to deal with are growing up (just preparing XXKPI) so I prepared a Batch Farm used to do the dirty job avoiding human errors...

...Obviously I check pre and post by Hand...

...Test on My Next...

...Share...

Once the Script will be STANDALONE FUNCTIONALE I'll share it too!

No luck needed here...

Studying Brick deep inside, while the Flash operation doesn't touch the first BIOS code (mibib, ecc...), if I don't make mistakes with Tass.ops or images too big I cannot really Brick while flashing...

...obviously I can always kill definitely my system with a wrong root command...

...All situations that I can resolve at last using Odin again...

Good Hint! Why do I need to journal a filesystem read only... I think I can deal with it occasionaly while readwriting something to it anyway!

THANKS!