yashsingh1/xdaforums huggingface dataset:
[Galaxy 3 Android Development] tom3q:
Well, I have plans to upstream at least support for S5P6442 (on top of existing code for S5PV210) and basic support for Apollo. Basically what is present in my tree should be already quite ready for mainlining maybe with the exception of some fixup commits that should be squashed with commits they fix (e.g. all patches to Apollo dts should be squashed to a single patch adding the dts).

U-boot as a second stage bootloader is a quite good idea, as it would eliminate the need to use Odin at all. You would just flash u-boot instead of kernel to "boot" partition and u-boot would boot your kernel from a dedicated UBI volume. It should be quite easy to get it running using already existing S5PV210 support in mainline u-boot with low level hardware initialization bypassed (as it's already initialized by Sbl).

As for UARTs, in addition to ttySAC1, which can be used as serial console to the AP through the microUSB connector, there are two more, ttySAC0 and ttySAC2, which are connected to bluetooth and modem chips respectively, but they aren't of much use for debugging purposes.
[Galaxy 3 Android Development] tom3q:
Sorry, but this is bull****. What kind of support from Samsung you need to mainline this? It's all up to the kernel community (e.g. maintainers) to review and eventually pick up respective patches if they get posted. Of course this needs to be bidirectional cooperation - community does review, you fix your patches. As for support itself, there is some apparently, otherwise you wouldn't have platforms like S3C64xx or S5PV210 in mainline.

See my reply to [MENTION=2115361]swiftgeek[/MENTION] above.

This is quite likely.

Anyway, with this new code base, you don't have to duplicate S5PV210 code, as it's almost entirely reused. The support for S5P6442 itself in my tree is almost entirely complete, since most of the low level code of S5PV210 can be reused. The remaining part are mostly drivers for peripherals that are different, namely MFC v1 and G3D. MFC v1 is in fact a slightly modified version of licensed CodaDx6 IP, which I already have a V4L2 driver for (see my coda-ng branch) and the G3D is already well known by us. So in general the most of work will be getting all the Apollo-specific chips to work at all and to work in Android.
[Galaxy 3 Android Development] hillbeast:
[MENTION=4117753]tom3q[/MENTION]

I have cloned your kernel 3.14 and compiled it fine using the s5p6442_defconfig. The only setting I changed in the config was to have it compress using LZMA as my build machine is using and old Ubuntu and doesn't support LZ4, however it won't boot. I'm not sure if there is something else I need to copy or edit or what, but this is all I get:

Starting kernel at 0x22000000...

Uncompressing Linux... done, booting the kernel.

Error: unrecognized/unsupported machine ID (r1 = 0x00000914).

Available machine support:

ID (hex) NAME
ffffffff Samsung S5PV210/S5PC110/S5P6442 (Flattened Device Tree)

Please check your kernel config and/or bootloader.

Is the ID built into the kernel supposed to be ffffffff?
[Galaxy 3 Android Development] moikop:
Once you've built the zImage, do this:

cat arch/arm/boot/zImage arch/arm/boot/dts/s5p6442-apollo.dtb > ../zImage

That adds the needed information for the kernel to start. After that flash the resulting zImage and it should be fine.
[Galaxy 3 Android Development] hillbeast:
That's what I was missing. Thanks.
[Galaxy 3 Android Development] hillbeast:
Got it all figured out now (kernel 3.13-rc5), and got Debian sort of booting (by sort of I mean it's clearly booting, I just can't do much because the shell is on the phones display, not my serial console). I downloaded a Raspberry Pi image and dumped it to a spare SD card. Now I'm going to try get an Android initramfs to boot. I want Android more than I want Debian.
[Galaxy 3 Android Development] moikop:
I don't remember if when the fb console was active, the serial one was left out. If that's the case, you just have to disable the it, here:

https://github.com/tom3q/linux/blob/v3.14-s5p6442/arch/arm/boot/dts/s5p6442-apollo.dts#L35

Just remove "console=tty1" and *I think* it will display everything in the serial console again (I think I did that but I don't remember well).

If you mean just the initfs, then take tom3q's droidboot one. Works with very little modification.

But if you mean Full Android, it'd have to be a version with ion (we don't have pmem in there). I'm just saying because we can't use marcellusbe's CM7 and expect it to boot, due to lack of pmem.
[Galaxy 3 Android Development] hillbeast:
Yeah I know about the cmdline being specified in the device tree. I'm not sure if that's necessary because it can't pick it up from the bootloader or what the deal is. I've removed the console=tty1 anyway for the Android initramfs. I'm trying to get ICS working but recovery is throwing a segmentation fault. Not sure what that's all about. I need to track down all my good files.

EDIT: Should mention even when removing the fbcon from the cmdline, I still can't get the shell on the serial console. I think it's a default that Debian resorts to: put the shell on the fbcon over using the serial console. Makes sense because not everyone would have a serial console, whereas normally everyone who has a screen also has a keyboard and mouse.
[Galaxy 3 Android Development] tom3q:
The command line specified in device tree is supposed to be a safe default. Still, for debugging purposes, it lets you add arbitrary kernel parameters quickly.

AFAIR Debian already has a serial console configured in inittab, but it's on ttyS0, while samsung-serial driver registers its ports as ttySACx. You need to adjust it manually and, if I remember correctly, also add entries for ttySACx to /etc/securetty.
[Galaxy 3 Android Development] tom3q:
Great, this is a nice step forward, thanks. I'd like to add one minor comment about UBI, though.

The recommended setup is to create one large UBI device on a single MTD partition occupying the whole user-accessible space of MTD device and then create volumes on it. This is because with such setup you will have block wear spread across the whole UBI device (i.e. all UBI volumes on it), so, for example, free blocks of /system will not need to occupy any physical blocks, letting other volumes introduce less wear and have faster writes, due to more spare blocks available.
[Galaxy 3 Android Development] marcellusbe:
Thanks for your help. Now, it looks good but I'm not sure about the partition's sizes.

~ # ubimkvol /dev/ubi0 -N system -s 220MiB
Volume ID 0, size 909 LEBs (230842368 bytes, 220.1 MiB), LEB size 253952 bytes (248.0 KiB), dynamic, name "system", alignment 1
~ # ubimkvol /dev/ubi0 -N cache -s 40MiB
Volume ID 1, size 166 LEBs (42156032 bytes, 40.2 MiB), LEB size 253952 bytes (248.0 KiB), dynamic, name "cache", alignment 1
~ # ubimkvol /dev/ubi0 -N userdata -m
Volume ID 2, size 815 LEBs (206970880 bytes, 197.4 MiB), LEB size 253952 bytes (248.0 KiB), dynamic, name "userdata", alignment 1
-------------------------------------------------
~ # mount
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
nodev on /tmp type tmpfs (rw,relatime)
tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
/dev/ubi0_0 on /system type ubifs (rw,relatime)
/dev/ubi0_2 on /data type ubifs (rw,relatime)
/dev/ubi0_1 on /cache type ubifs (rw,nodev,noatime,nodiratime)
[Galaxy 3 Android Development] apoorv24:
Hey guys....just wanted you people to know that you have a tester (me :D) available to test this kernel as and when required....just let me know :)

Since I am not using my G3 as my primary driver so I can test any experimental features as well if you want...
[Galaxy 3 Android Development] lgm888:
Hello, Great God, when creating a new ROM.

---------- Post added at 09:54 AM ---------- Previous post was at 09:53 AM ----------

Hello, Great God, when creating a new ROM.
[Galaxy 3 Android Development] chraso:
Hi hillbeast,

Wow you are an amazing guy & an amazing team.

Can I request you help on porting the same to gt-i5500 aka galaxy5(or corby some say).

Our leading developers psyke83 have succeeded porting the 3.0.31:

http://xdaforums.com/showthread.php?p=51609828

but, having a 3.4.x kernel will be a huge success.

Waiting for your reply & if possible the support also.( You can see all the work done by psyke83 on this page http://madteam.co/forum/development-8/(devs-only)-mtdonenand-driver-development/)

Hope for your support.
[Galaxy 3 Android Development] mysteryno46:
Is there any final build for 3.4.x Kernel.

Where have we reached [MENTION=3404423]marcellusbe[/MENTION] [MENTION=4117753]tom3q[/MENTION] [MENTION=3633911]hillbeast[/MENTION]? :fingers-crossed:

I'm too ready to test the latest updates on this Kernel. Eager to have a final build soon. Thanks mates you are a great team together.

Thanks a lot once again. Do tag me in the post when you want me to test something. :good:
[Galaxy 3 Android Development] tom3q:
I'm afraid we're not much ahead of what has been announced last time. I've prepared a base kernel tree with basic hardware working, [MENTION=3404423]marcellusbe[/MENTION] managed to get a working recovery and nothing else I'm aware of. I need to rebase the kernel tree to latest linux-next to get rid some out of tree patches, but that's pretty straightforward. My primary work is going on graphics side, where I'm developing a Gallium3D based OpenGL ES 2.0 support for the FIMG-3DSE GPU to get reasonable hardware acceleration on Android 4.x, which is optimized for OpenGL ES 2.0 (as opposed to OpenGL ES 1.1 supported by original OpenFIMG driver).
[Galaxy 3 Android Development] mysteryno46:
Appreciate your Efforts no matter what.

Everyone knows that work is in progress, no matter if slow. You guys are trying to give a rebirth to a device which most of people won't even think of. Your efforts are much appreciated.

Currently I'm on CM10. Previously was on Kyrillos 10.2. I'm having very severe battery issues with the phone. Battery fluctuates too much and you just can't make out when the phone will get switched of. :mad: While charging, it instantly goes to 96% then 100%, after discharging goes back to 34%, sometimes 60%. No matter how long you keep it connected to charger, when detached, battery becomes very unstable. Also I'm not able to use internal sdcard. I can only download files, or receive files via bluetooth only when I have Ext sdcard inserted. :(

What do you think should be the problem? Battery Doesn't look swollen at all. So, I think battery is not the issue. I'm not using it because of this. Suggestion highly appreciated.

Thanks alot in Advance.
[Galaxy 3 Android Development] tom3q:
Thanks.

How old is the battery (years)? This model (also used in GT-i5700) is known (at least some series) to fail after about 1.5-2 years of use with symptoms exactly as you described. It is known to happen even faster if over-discharged, which can happen on kernels with battery drivers with lowered shutdown voltage threshold (not sure if such was available for Apollo; was for sure for Spica).
[Galaxy 3 Android Development] mysteryno46:
Trying to flash stock firmware.

Yes, battery is very old. Probably more than 4 years. This is the one that came with the phone itself. [MENTION=3404423]marcellusbe[/MENTION] said try flashing Stock firware and see what's the result. I think it is because it is too old to live. Still I wanted to ask that if I want to flash stock firmware. Do have to take any precautions before flashing it via odin? Coz I'm on AOKP currently. I know that downgrading has always been an headache.

Let me know something if useful.

Thanks...
[Galaxy 3 Android Development] raasm007:
It's the battery. I had the exact same problem (battery not swollen either) but upon changing the battery all was fine.

.:cheers:.
[Galaxy 3 Android Development] linr76:
Funny i have the exact same problem with the battery. Not using the device either. Want to build Firefox os for it but time is a premium...
[Galaxy 3 Android Development] balamu96m:
That's really interesting....Firefox OS.....I can also try to give you some hand but at least a month later from now....
[Galaxy 3 Android Development] linr76:
well it's a huge pain actually, since the porting is not documented really.

basically Firefox OS works for any device that has a Cyanogen Mod ICS port, since you will base some of your work on their manifest.xml

from there its a lot of guesswork...
[Galaxy 3 Android Development] balamu96m:
Oh....really interesting........

25$ Firefox OS phone has 128mb ram...so in case we get a build, our hardware might not have any problem.....I'm afraid the Open GLES 2.0 might trouble us, but I hope tom3q can solve it to a great extent.......... let us not pollute this thread.......

Can you start a new thread to bring on all related discussion to a single thread??
[Galaxy 3 Android Development] tom3q:
Just wanted to let anyone interested know that I have rebased my v3.14-s5p6442 onto latest linux-next (pre-3.16), cleaned up the branch a bit and fixed few things here and there. You can find it as usual on my linux repo on github. Branch name is v3.17-s5p6442. At first glance, everything that worked before is still working.
[Galaxy 3 Android Development] macia10:
Sorry for Hijacking this thread but will there be anything still done for Spica? It's been really quiet for some time there. :(
[Galaxy 3 Android Development] tom3q:
I have pretty much the same done for Spica, as both SoCs are quite similar and S3C6410 (of Spica) has even more support already in mainline kernel. I'm currently working on a complete shader compiler for my Gallium3D driver for both SoCs, which should get me mostly working OpenGL ES 2.0.

On the other hand I wouldn't hope for any miracles on Spica, especially due to low amount of RAM and much worse upstream support for rest of hardware (would you believe that even the BCM4329 WLAN chip is supported in mainline kernel, as opposed to BCM4325 which is unstable with new firmware required by new drivers).
[Galaxy 3 Android Development] macia10:
Oh I didn't hoped for newer android version cm7 is enough for it but there was nothing new for it for a loong time ;p I don't hope for new stuff to be working but update would be nice :)
[Galaxy 3 Android Development] hillbeast:
Since Android 4.0, Google has been gearing Android towards more modern processors and architectures. ARMv6 was old back in 2010 when this phone came out, let alone 2014. Now they're moving towards ARMv7 and ARMv8, and I wouldn't be surprised to see ARMv7 support drop out of official Android in a few years time. ARMv6 is just really old, as is the ARM11 processor core. No support for NEON, no out of order executing, short pipelines, outdated branch prediction units, single core, low clock, etc. There's no benefit to Google developing on ARMv6 anymore. Google are more interested in ARMv7 and x86 now, both of which have better support for out of order (well... Cortex A9 and A15 and Krait do, and I think Atom now does).

As a result, KitKat does work on ARMv6, and would work on the SG3, but I wouldn't expect wonders. There would be a LOT of emulation needing to be done to emulate ARMv7 instructions, especially when you are working with closed source functions like Google Apps.

EDIT: I should mention that the only relatively popular modern system I know of that still uses ARMv6 is the venerable Raspberry Pi, but that is more a Linux system than an Android system.
[Galaxy 3 Android Development] PureTryOut:
So, sort of reviving this thread. I used to use this device, and I still have it in my closet, fully working. I think it's a shame to see it die just because newer Android versions don't support it any more.

I'm part of the postmarketOS project (please check it out before responding to me), and this device would be perfect for it!

I've been having a go at compiling this kernel, as it seems the most promising to me (2.6.x is really too old for any modern Linux distro). However, I've been having some problems.

/home/pmos/build/src/android_kernel_samsung_s5p6442-f097f36a538ed37e528cff416b09b226004dff1c/scripts/gen_initramfs_list.sh: Cannot open '../initramfs/'
make[1]: *** [/home/pmos/build/src/android_kernel_samsung_s5p6442-f097f36a538ed37e528cff416b09b226004dff1c/usr/Makefile:67: usr/initramfs_data.cpio.xz] Error 1
make: *** [Makefile:945: usr] Error 2
make: *** Waiting for unfinished jobs....

Probably some really simple to fix error, but I'm stuck nontheless. Seeing the last commit to the repository was 4 years ago, it might just be some local package which works differently from back then and now causes different results.

I've pushed my progress so far to this repository.

Is anyone interested in helping me port postmarketOS to this device, and potentially even port the device to mainline Linux in the future? And is there anyone that has a clue how to fix this (and any following) error(s)?
[Galaxy 3 Android Development] hillbeast:
Okay so the issue is with the initramfs. Back then I used a really hacky method of compiling with it, but that's kind of because this device doesn't support a boot.img where you can compile one without the other.

For now just tell it to compile it without an initramfs. That should be in the make menuconfig. If dig out my Gaoaxy 3 to assist you but I don't even have a Linux box anymore and have little to gain from a single core ARMv6 CPU that even when over clocked to 1.2GHz is slower than even one core in the crap $20 phones that networks are basically giving away these days.

I still have an attachment to this device but let's face facts, there's nothing this device can do that makes it worth keeping around. Even for an MP3 player it's almost too slow.
[Galaxy 3 Android Development] PureTryOut:
That's disappointing. I run nothing else, it's the best OS out there in my opinion ;)

I have to disagree. I'd keep it even because I can hack around with it. Also, it could make a nice feature phone if you'd put something like QtMoko on it.

It just needs updated software. Of course such a device could never make a worthy replacement for any recent smartphone, but it doesn't need to be. It has it's own uses, even if it's just for nostalgic sake.

Anyways, I'll hack around a bit more and I'll try your suggestion. I will report back if I get running!

**EDIT:** Quick update, I got it compiling actually, using GCC6 and with initramfs. The initramfs you had on your Github even. The "initramfs" folder just had to be placed next to the kernel source. I'm going to look for an SD card now and see if I can get anything booting.
[Galaxy 3 Android Development] tom3q:
OK, I checked the sources. It looks like all the chips from S5P series are very similar, but indeed S5P64x0 is closest to S5P6442, so the work should be pointed into adding support of S5P6442 under S5P64x0 tree.

There are some subtle differences in memory map between S5P6442 and S5P6440, but same goes for S5P6450, which is also supported by the same code, so it just has to be extended to account for those differences.

Moreover, documentation for s5pc100, s5pc110 and s5pv210 is available (with little googling), so putting it together with original sources of G3, we can consider the S5P6442 chip as almost fully documented.
[Galaxy 3 Android Development] hillbeast:
Okay. I shall see what needs to be done to add s5p6442 to mach-s5p64x0
[Galaxy 3 Android Development] cdesai:
Forgot to post one thing.

Talked about it with hillbeast yesterday, and then i deleted the kernel repo and repushed it

Now there's no linux-samsung, we'll be using android-3.0.

android-3.0 tracks upstream to android common kernel

apollo-3.0 is what we'ld be working on ;)
[Galaxy 3 Android Development] tom3q:
IMHO we should rather fork android-3.4. Support of S5P SoCs is evolving continuously and there is a lot of good stuff added between 3.0 and 3.4. Not even saying that I had to backport the whole V4L2 subsystem from Linux 3.3 to my spica-3.0 tree to be able to port s5p-fimc and s5p-jpeg drivers for s3c6410.
[Galaxy 3 Android Development] hillbeast:
Agreed. It's always best to work with the newest code, and it's not like s5p6442 support is going anywhere seeing they removed that a long time ago.
[Galaxy 3 Android Development] tom3q:
Well, it is, not exactly as support for s5p6442, but as support for S5P/Exynos series. They removed only the low level SoC support, but support for all the IPs/peripherals (which are mostly common over the series) is being continuously developed.
[Galaxy 3 Android Development] hillbeast:
Oh no I mean they can't exactly remove it more than they already have. The basic support for s5p is there yes, but not the exact mach code for s5p6442. Should have worded that better, and yes s5p is constantly being developed as Samsung have stuck to the same design for their SoC for a while now and people want to develop on it.

Also for everyone else, I should mention I updated one of the posts on the first page to give people some information they should know about kernel 3.x

http://xdaforums.com/showpost.php?p=25865886&postcount=4
[Galaxy 3 Android Development] tom3q:
OK, fine.

By the way, I'm going to look into G3 kernel as soon as I finish implementing that freaking libcamera for Spica (and G3 after we get this kernel running with s5p-fimc and s5p-jpeg drivers). The whole low level camera API of Android is really bad, making it pretty hard to design libcamera nicely.

My plan is to compile the original kernel with minimalistic configuration (only things needed to start recovery, see it on the screen and have working adb) and kexec enabled with kexec tools included in initramfs. This will simplify testing kernel builds (and recovering from builds that fail to boot) and debugging them (ram console can be captured from the working kernel after a reboot).
[Galaxy 3 Android Development] hillbeast:
Yeah that's where I want to aim it as well. Initially if I can just get it to busybox sh via UART then I would be happy. Once we can get a UART output it will make all the debugging a lot easier as we can just see the UART dump. Just got to find out why in all the previous attempts I've gotten nothing. How do I enable the early init console that you mentioned?
[Galaxy 3 Android Development] tom3q:
As far as I remember, there should be an option in "Kernel hacking" called "Kernel low-level debugging functions" to enable early serial output and "S3C UART to use for low-level debug" to select to which port should it go. Also for even earlier output (in kernel decompressor) there is an option in "System type" called "S3C UART to use for low-level messages", which also selects the port.
[Galaxy 3 Android Development] hillbeast:
Okay. Looking at the current option it says 0. Now do you know if it counts from 0 being the first UART, or does it count from 1 and 0 means 'none'?
[Galaxy 3 Android Development] tom3q:
0 is the first port.
[Galaxy 3 Android Development] hillbeast:
Okay. I took a look at the Samsung kernel and it has 1 in there. I will try with 0 and if it doesn't work then I'll try 1.
[Galaxy 3 Android Development] stubborn_d0nkey:
Our community is awesome!

AFAIK he only hosts on github, he doesn't use for management/commits/whatever the exact lingo is (I have never used got(hub))
[Galaxy 3 Android Development] tom3q:
As far as I am aware of, all the Linux kernel development is back on kernel.org.
[Galaxy 3 Android Development] stubborn_d0nkey:
Which means it's not on github (which is what I was saying) :D
[Galaxy 3 Android Development] tom3q:
Yeah, I just confirmed it.

Anyway, Git is Git, it doesn't matter where the repositories are hosted.
[Galaxy 3 Android Development] andreapier:
Did you mage to get uart initialized? Or this project has stopped for some reason?

Please, i would really see our phone without any samsung software to understand its full capabilities.