Messing around with Galaxy S and replicant
PaulK
paulk at paulk.fr
Fri Sep 30 21:11:33 UTC 2011
Le vendredi 30 septembre 2011 à 01:52 -0300, Igor Almeida a écrit :
> Hi guys,
>
> I've been lurking around asking stuff about the Galaxy S (GT-I9000)
> but never got a chance to summarize what I've been trying to do. Here
> is an attempt to do just that, and would be great if you could show me
> mistakes and give suggestions on where to go.
>
> I took what seemed absolutely necessary from the cyanogenmod
> galaxysmtd files and copy/pasted it to create a replicant_galaxysmtd
> product, always keeping an eye on paulk's Nexus S gingerbread files:
>
> https://gitorious.org/~igoralmeida/replicant/igoralmeida-manifest
> https://gitorious.org/replicant_tests/android_device_samsung_galaxysmtd
> https://gitorious.org/~igoralmeida/replicant/igoralmeida-android_vendor_replicant
>
> Because there is no vendor/samsung tree, none of the binary blobs
> would be included. There are also some kernel modules mentioned in
> device/samsung for the galaxysmtd which I'm not sure are free, as well
> as some scripts from teamhacksung and the cyanogenmod guys.
>
> Anyway, 'make -jN bacon' seems to run ok [1] (trying to make
> 'distimages' before 'bacon' doesn't work: it dies prematurely with a
> lot of 'ignoring old recipes' messages [2]) and creates the replicant
> ota .zip files [3,4], so my next step was to compare it to
> cyanogenmod's packages [4,5] and take a look at what was missing.
About make distimages failing, it seems, according to your error
messages to append as a result of:
make: Nothing to be done for `distimages'.
The warning about overridden stuff is normal and appends all the time
(on Replicant 2.2 too).
If images come to work with heimdall easily, we'll have to look at this
in details in order to make it work at first try. Otherwise, if the only
way to flash images is to use .zip files, then this is a less important
issue.
Well, what we usually do to see what we we won't include in Replicant is
to look at the extract-files.sh script: it contains all the non-free
stuff that CyanogenMod includes. It's this one:
https://gitorious.org/replicant_tests/android_device_samsung_galaxysmtd/blobs/gingerbread/extract-files.sh
I'm afraid that the list is quite long: some components will probably be
replaceable, some others maybe won't be needed but in any case, the
first time you'll get it working, not a lot of stuff will work…
(I expect you to get a green-ish screen.)
> I don't understand the difference between the ota and update- packages
> [7]. The same happens with cyanogenmod, but to a lesser extent [8]. I
> also diff'd across builds, just for the sake of completeness [9,10].
> >From [10] you can notice some important files are missing, especially
> updater.sh ( https://github.com/CyanogenMod/android_device_samsung_aries-common/blob/gingerbread/updater.sh
> and /bml_over_mtd.sh) and some binaries for the actual flashing.
I have no idea about the differences between ota and update- packages as
I almost never head to deal with it. Though, make bacon is the way
CyanogenMod packages are made, so I bet the packages you build using
make bacon would work as well as CyanogenMod ones.
About the missing files, I assume that these are not needed if you use
recovery to flash the images.
> So the .zip package would probably not work from my recovery mode. Am
> I right to assume the file in
> META-INF/com/android/google/updater-script is the first thing called
> when I "Apply a .zip file from sdcard" in recovery mode? I was looking
> [quickly] for its origin, but couldn't find it.
I remember that I once looked at it, and it was instructions to copy the
files on the right place, check the md5 sums, etc.
> I then went on to take a look at flashing via heimdall 1.3. The first
> thing I did was download the PIT file and have it printed on my screen
> [11] and then my understanding of the system starts to fade:
> cyanogenmod was supposed to create YAFFS2 images, as suggested in
> /proc/partitions, /proc/mtd and mount commands in the shell, showing
> me a bunch of mtdblock* names for boot (0), recovery (1), system
> (...), cache, efs, radio, datadata and reservoir (7); but the build
> logs show system.img created with make_ext4fs. Also, while heimdall
> DOES have flags for system/dbdata/etc, I assume they would obey the
> partition layout with RFS from the PIT file, so I don't understand how
> could cyanogenmod flash it without changing the partition layout and
> filesystem types. My guess is that it works via bml_over_mtd, but I
> could not find a website explaining the inner workings for that.
My bet is that if CyanogenMod works with the recovery image, the
recovery images knows the correct adresses for each partition name, so
it doesn't have to recreate a partitioning layout. Filesystem type isn't
needed to flash because it just writes the filesystem as is, would it be
ext4 or yaffs2 or whatever (though, some may perform images check
before, like Nexus S fastboot device-side software) and it's up to the
kernel to read the image with the correct fs type.
I think ext4 would work fine on Galaxy S as it's already used in Nexus
S. If it doesn't work, you will anyway not break anything. So it's worth
trying ext4.
> Apparently the Galaxy S is pretty robust when it comes to bricking if
> all you do is above the bootloader, so this is not a "hey can you
> confirm I won't brick it" so much as a "hey can you help me understand
> how this porting thing could work here?" kind of e-mail
Yes, it's highly unlikely that you'll brick your device flashing an
image. Even if Heimdall screws, you'll always be able to deal with it
with the non-free Odin, or boot recovery. And if it screwed at flashing
the bootloader, there are still modified
unofficial-and-barely-legal-bootloaders that can work and the ultimate
solution that remains is JTAG. It's unlikely you'll ever get to use JTAG
to solve a screwed write.
> . My next step after that would be following the How_to_port wikipage, starting with
> reference-ril and logcatting stuff.
The porting stuff assumes your device is MSM, while the Galaxy S isn't
at all. Consider me as your blood-and-flesh porting-guide as I did a
consequent part of the work on the Nexus S :D I'll probably make a
porting guide for Samsung devices as these become to be popular and
asked to be support by our project a lot.
Refernce-ril won't work, a RIL for samsung has to be/is being written
but is not ready at all at this stage. Basically, I was able to boot the
nexus s modem, understand mostly how communication with it works and to
ask for IMEI and a few other stuff. We're not at stage where we are
connected to the network and ready to send and receive text messages or
calls.
Thanks a lot for working on this, we really do appreciate! Providing all
the relevant infos as you did just right here was also a very good
idea :)
Feel free to ask more details/infos/questions/whatever about my answers,
some of them may not be that relevant.
> Stuff in http://igoralmeida.devio.us/replicant/ (except .zip files)
> [1] LOG_MAKE_BACON
> [2] LOG_MAKE_DISTIMAGES
> [3] replicant_galaxysmtd-ota-eng.igor.zip
> [4] update-cm-nightly-signed.zip
> [5] cyanogen_galaxysmtd-ota-eng.igor.zip
> [6] update-cm-7.1.0-RC1-GalaxyS-KANG-signed.zip
> [7] Diff_replicants.html
> [8] Diff_cyanogens.html
> [9] Diff_otas.html
> [10] Diff_updates.html
> [11] GALAXYS_CMOD_PRETTY_PIT
> [12] LOG_BRUNCH (pure cyanogenmod build log using their tree)
>
More information about the Replicant
mailing list