[Q] Porting Meego to the Tab, some Android noob questions before I start

---

Hi chaps,

I've just bought a Galaxy tab with plans to port Meego to the device.

I'm new to all the Android stuff, and tbh the myriad methods for doing this/that/the other and the relative lack of explanation of what's actually being done in these various methods/tools is quite confusing (and worrying).

So, if you'll bear with me, I have a few questions which are probably quite basic.

I've rooted my Tab using SuperOneClick, no problems there, I also understand that there is a leaked flashing tool called (Multi)Odin and an open source flashing tool called Heimdall. I understand adb.

So onto the questions:

Before I start messing about, how should I backup my existing firmware image? I see people talking about taking image dumps using dd, or Odin or Heimdall. What is the preferred method? And how should one then restore the device from these backups?

Alternatively is it possible to simply download the firmware directly from Samsung (I see links to later firmware, but really I'd be happy with what I have currently - P1000XXJK5 and FROYO.XWJJ7)?

I'm assuming that the best installation method would be to replace recovery, then I can add my own kernel and have it boot a rootfs mounted on the external SD card for example. Any thoughts?

I've seen one thread about people compiling their own kernels, with panics and the like which are solved by giving the full path to the initramfs extracted from the existing image. Any clues as to why the built version doesn't work? This is not so important as I can have a look at this when I build the Samsung source.

Is anyone looking at the bootloaders? Is there any information anywhere about them (as changing the bootloader to allow selection of the kernel to be booted would make life easier)?


Thanks for your patience!

Ok, so to partly answer myself, I see www dot samfirmware dot com has links to downloads of firmware images.

I'd really prefer to generate my own image of what's currently on the device rather than trusting a download site, but I guess it's better than nothing. Does anyone know how these images were generated anyway?

Originally Posted by lardman

Ok, so to partly answer myself, I see www dot samfirmware dot com has links to downloads of firmware images.

I'd really prefer to generate my own image of what's currently on the device rather than trusting a download site, but I guess it's better than nothing. Does anyone know how these images were generated anyway?

Samfirmware get their images direct from Samsung insiders. They are not dumps.

If you want to dump from your device search "rotobackup" here in the dev forum.


Sent from my GT-P1000 using Tapatalk

Originally Posted by alias_neo

Samfirmware get their images direct from Saunaing insiders. They are not dumps.

Ok that's reassuring.

Originally Posted by alias_neo

If you want to dump from your device search "rotobackup" here in the dev forum.

Great, just what I was looking for, many thanks

So some more questions:

Any limit to the size of the kernel? Presumably just the size of the partition (which after extracting the image for backup seems to be a pretty large 15.4MB)?

What do all the .rc files in the raminitfs do? They are as follows: fota.rc, init.goldfish.rc, init.rc, init.smdkc110.rc, lpm.rc, recovery.rc

The init.rc is the normal init.rc file, so that's fine. Presumably the recovery.rc file is run if the bootloader detects that recovery mode is wanted (holding down keys during boot). The init.goldfish.rc? I guess this is to do with the emulator, though why it would be in a release image I don't know.

I assume that init.smdkc110.rc is automatically run somewhere along the line, though I don't see where it's started.

Any thoughts on lpm.rc and fota.rc? Are multiple .rc files run for the normal and recovery boots?

Thanks

lpm.rc is for low power mode that displays battery charging animation
goldfish is for running the rom under qemu.

backup your rom using rotobackup. compile samsung's kernel from sources, mix up default initramfs with meego's init scripts. pack all Meego stuff into loop mounted disk image. then flash zImage to kernel and your disk image to factoryfs using heimdall. I assume you have experience hacking N8xx/N900 and Maemo or Meego?
factoryfs is around 300MB so I think it should fit Meego and it (and kernel) can be easily restored with heimdall.

Thanks for the comprehensive reply

Yes I do have experience hacking Maemo/Meego, though have never really had to fiddle with init scripts before and this is as good a reason as any to learn.

I'd actually like to dual boot, so am modifying recovery.rc to bring up the Meego system on the external SD card.

Am just fiddling about building extra kernel modules now (needs btrfs for my image for example) and modifying the recovery.rc file.

Hmm, well I was all set to go and flash my new zImage and was looking for the heimdall command line, when I saw this at the top of one of the threads in this part of the forum (http://forum.xda-developers.com/show...php?t=870690):

Restoring to factory after using this process (you need using stock images):

heimdall flash --kernel stockzImage --recovery stockzImage --factoryfs factoryfs.rfs

Which has made me worry a bit that I've missed a recovery partition with its own kernel and wrongly assumed that the same kernel is used for both recovery and normal running, just with a different .rc file to be interpreted by init.

Any thoughts?

Do we trust the partition sizes reported here: http://forum.xda-developers.com/show...0&postcount=14

They seem very small for the kernel partition. I used RotoHammer's dd method to grab the contents of the partitions as a backup, so am assuming the sizes shown above are not correct (or represent something else?)

Going back to RECOVERY and ZIMAGE partitions - the ZIMAGE partition contains a recovery.rc, the question is really whether, even if they use the same zImage in both the ZIMAGE and RECOVERY partitions, the version in the RECOVERY partition is actually booted if recovery mode is selected (by holding the up volume key, etc.)? OTOH it may be that the RECOVERY partition is either empty or unused, has anyone tested specifically to see whether recovery.rc is run from the ZIMAGE partition?

Well I think I can answer my own question there, I flashed my modified kernel (modified recovery.rc) only to the KERNEL partition, and it boots normally if I don't touch anything, and just gets stuck on the first Samsung screen if I boot in recovery mode.

So it's doing something, I just can't tell what. Not sure if any kernel messages are getting lost behind that image, or perhaps they aren't even output to the framebuffer at all. I seem to remember seeing something about disabling the splashscreen so I'll go and have a look for that. Anyone got any other suggestions?

P.S. I also note there's a flash of screen corruption as the device starts up with my new kernel, I don't remember seeing that before. Is this a usual occurance?