yashsingh1/xdaforums huggingface dataset:
[Galaxy 3 Android Development] hillbeast:
The IRQs have been fixed up, and it doesn't really change anything, but it is something that needed done. I'll keep looking through comparing various defines to old Samsung kernel and find more problems.
[Galaxy 3 Android Development] z3c0:
How far away would you say is the kernel development from going independent of the UART connection?

(i.e. debugging becoming feasible via USB)

Is it at all reasonable to think one could read up on the skills needed to contribute at such a stage?

Where should I start? I got some experience with shell scripting / GNU toolchain but still know fairly little about hardware design and never tinkered with kernels.

(question goes to moikop / tom3q etc as well)
[Galaxy 3 Android Development] hillbeast:
Kernel can be debugged over the display right now. Use fbcon and it'll work. Its small and will be difficult but its possible.

USB is still miles from working. I haven't done any work on that. The switch chip works, but the USB controller isn't working yet.
[Galaxy 3 Android Development] balamu96m:
Same with me......I can also try to contribute to my best when it is USB debugable.....:)
[Galaxy 3 Android Development] moikop:
I'm sorry guys, but I'm stuck (and with something rather stupid really..). I've tried anything I could think of.. any ideas? @hillbeast @tom3q @anybody anything is welcome.
[Galaxy 3 Android Development] balamu96m:
This may be dumb-ish:

Maybe the ramoops' memory address is not set properly that it says device not found??
[Galaxy 3 Android Development] hillbeast:
USB controller isn't configured at all. It doesn't even initialise. That's why it says device not found. As I said, I haven't worked on the USB controller. I've added a few addresses for it and IRQs but that's only the tip of the iceberg. Most likely those addresses arent even right.
[Galaxy 3 Android Development] moikop:
Nevermind... it solved itself.

So, where were we? :p

I was planning to work on UBI, but suddenly my sd got completely corrupted (yeah, got one problem down, but another came up. Only that this one is much easier to solve, it's only going to cost a couple of bucks :). Thankfully all I had in there was the kernel binary).

What else is there that needs to be fixed "immediately"?
[Galaxy 3 Android Development] hillbeast:
The main issue right now is the fact or won't run binaries correct. They don't close or behave weirdly.

EDIT: I haven't had much time to myself over the last month hence why progress slowed down again, but its coming up to my holidays so I might get some time to work on the kernel again once
[Galaxy 3 Android Development] moikop:
I've been looking into the clockevent device and it seems to be just fine. Compared it with .26 and .38 code, and checked it's clock rate and it's correct. Is there anything else that may be causing this issues?
[Galaxy 3 Android Development] z3c0:
Do you think you will pick development up again, eventually?
[Galaxy 3 Android Development] hillbeast:
At some point. At the moment I'm just busy with work.
[Galaxy 3 Android Development] hillbeast:
I got bored. SO SUE ME!!! I'M SORRY!

Starting kernel at 0x22000000...

Uncompressing Linux... done, booting the kernel.
6Booting Linux on physical CPU 0x0
5Linux version 3.10.0-gd26dfc7-dirty (hillbeast@hillbeast-virtual-machine) (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #Test Wed Aug 14 23:21:28 NZST 2013
CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: SMDK6442
Memory policy: ECC disabled, Data cache writeback
0Kernel panic - not syncing: ERROR: Failed to allocate 0x1000 bytes below 0x0.

dCPU: 0 PID: 0 Comm: swapper Not tainted 3.10.0-gd26dfc7-dirty #Test
Backtrace: invalid frame pointer 0xc024beac
[Galaxy 3 Android Development] josip-k:
Nice. Please do something for xperia x8,cuz i broke my nexus xD
[Galaxy 3 Android Development] hillbeast:
What could I possibly do for the X8? I don't even have it.
[Galaxy 3 Android Development] ilievski.ace:
What it means that is booting ... ? And is working .. ?
[Galaxy 3 Android Development] alb3rtt:
It means he tried booting kernel 3.10 but it failed. I've got 3.10 on my s2, it is such an improvement compared to 3.0.xx and that is an improvement to 2.xx

It's not a huge difference but it feels smoother. The difference might be smaller on the galaxy 3
[Galaxy 3 Android Development] hillbeast:
I got bored so I tried getting kernel 3.10 to work, or at least to a similar state to 3.4. It was a lot easier than getting 3.4 to this point, namely because I know more about the processor now than I did back then, and also because I am no longer comparing it to the S3C64xx/S5P64xx, rather backporting a lot from S5PV210. This isn't me back to developing on the Galaxy 3, it's just me playing around because I got bored over the last few nights.

What you have on the S2, I assume is DorimanX kernel, or something similar? That's not really 3.10, that's just a lot of backported functions from 3.10 onto 3.0.y.
[Galaxy 3 Android Development] alb3rtt:
It is DorimanX but he got full 3.10.y booting on it with backports from 3.11.x

Working really good.
[Galaxy 3 Android Development] tom3q:
Sorry to burst your bubble, but [MENTION=3633911]hillbeast[/MENTION] is right. Based on diffstat between DorimanX's kernel and Android 3.0, 3.4 and 3.10 kernels, Android 3.0 is the closest one. A lot of things is backported from newer kernels, including 3.10, but this does not make it 3.10. He just changed the Makefile to set version to 3.10.

It's not fair to trick the users like this...
[Galaxy 3 Android Development] alb3rtt:
Aww :crying: I thought it was actual 3.10 and he said it was.... :(

It still works better than before but still...
[Galaxy 3 Android Development] tom3q:
Yes, it's sad that such things still occur in such big community with long history as xda.

Not saying that his kernel is bad, as I haven't used it. A lot of backports from newer versions might make it better than original 3.0.x. But I've been always fighting against made up descriptions posted by modders and this is yet another example of such.
[Galaxy 3 Android Development] josip-k:
Do you want one?
[Galaxy 3 Android Development] andreapier:
Wtf stay on topic
[Galaxy 3 Android Development] Stanislaus:
Hahaha what topic? Hillbeast isn't working on this anymore.
[Galaxy 3 Android Development] hillbeast:
Thats the thing about back ports: they can bring the performance of a newer kernel back to older kernels, but they're still limited by the original kernel. You can't fix bugs with back ports. The bugs usually are in device specific code, which won't get updated.

Also take the performance boost from 3.10 with a pinch of salt. The boost may more come from optimised or tweaked governors and such.

Not really. Don't even have time for my G3, let alone another phone.
[Galaxy 3 Android Development] m1trand1r:
ha....let's spoil the atmosphere in dorimanx thread now:D

Can you even post anything else than that?.....wtf?:p
[Galaxy 3 Android Development] m1trand1r:
Say what?, Say what?:D [MENTION=3633911]hillbeast[/MENTION] , [MENTION=4117753]tom3q[/MENTION] ?
[Galaxy 3 Android Development] tom3q:
I'm not sure whether this is supposed to funny or scary. I think his way of using Git explains everything, though.

But let me see, what kind of code "cannot be changed", by doing a "stupid diff" again. (As soon as my Git finishes fetching the enormously sized commits from his repo.)

Btw. Nobody said that his kernel is just a changed Makefile. If this is what he got from my words, then it is a completely wrong impression. My intention was to show that Linux 3.10 is a well defined set of files released by Linus Torvalds et al. (based on patches made by a lot of kernel developers from all around the world) and not some kind of patched Linux 3.0, even if 50% of the files are copied from Linux 3.10.
[Galaxy 3 Android Development] m1trand1r:
ma8 nothing from above....not scary nor funny....I'm just seeking for truth nothing more nothing less....and I respect both of you....I just wanna hear/read other opinions too:)...and since I know who you are....you seem to be correct person for this things....

:)
[Galaxy 3 Android Development] tom3q:
This is one of the most interesting commits from his repo:

https://github.com/dorimanx/Doriman...mmit/25a30998e905756abe919b6a2f57853ed2d70376

(Git still cloning, as github has been working really slow for me lately. 10% as of now.)

EDIT: To make this a bit more on topic, we (a group of people working on support for Samsung chips in mainline kernel) hope to enable device tree [1] support for S5PV210 in one of next kernel releases. Device tree enables people to describe SoC- and board-level hardware without things like board files or most of other code-based description of hardware, such as statically defined platform devices, interrupt numbers, base addresses in headers. See the code reduction in mach/exynos between Linux 3.10 [2] and 3.11 [3], when support for board files got dropped.

[1] - http://devicetree.org/Device_Tree_Usage

[2] - https://git.kernel.org/cgit/linux/k...ree/arch/arm/mach-exynos?id=refs/tags/v3.10.7

[3] - https://git.kernel.org/cgit/linux/k...e/arch/arm/mach-exynos?id=refs/tags/v3.11-rc5

How is this relevant to this topic? This means that the mach-s5pv210 directory and all the low level support code could be probably reused for S5P6442, which could be supported just by adding appropriate device tree listing the hardware it contains and things like their base addresses, interrupt numbers, etc. Just an idea in case someone gets bored again. :)

EDIT2: Git clone finished, diffstat done, here are the results (a diff against android/experimental/android-3.10 kernel): https://defuse.ca/b/ZP1v3SFm?raw=true . This is still far, far from anything that could be called 3.10. I'm not sure this can be even called Linux, since it has diverged so much from any kernel release that it looks more like a 3rd party fork of Linux. Notice how much even core kernel files differ, like those in kernel/, fs/, arch/arm/kernel, arch/arm/mm . Those are not files that have anything to do with platform-specific code.

EDIT3: Yet another diffstat of comparison with mainline Linux 3.10.y: https://defuse.ca/b/caMeQUXA?raw=true

EDIT4: Anyway, don't blame [MENTION=2376110]dorimanx[/MENTION] for this. He's not the first one to do such things, and not the last one probably. It is a common problem with a lot of the 3rd party kernels here on XDA or any other site. Unfortunately community development often doesn't go in pair with professionalism, as professionalism usually doesn't go with much free time left for community development.. [MENTION=2376110]dorimanx[/MENTION] is doing a lot of good for the SGS2 community, investing his free time into his work, probably learning a lot, but he's yet to learn an even greater lot.
[Galaxy 3 Android Development] hillbeast:
I agree with everything tom3q said but I'll also add that he points out some code can't be changed, and this is the code I referred to GMAT truly limits a kernel. Look at our 2.6.32 kernel. It's a total mess and that's what makes developing on this device hard.

Also I should add, with the amount of time some developers spend on back porting, especially on Samsung devices where access to an external UART console is so easy, that time could have been better spent on porting a whole kernel rather than just bits and pieces.

Edit: Also [MENTION=4117753]tom3q[/MENTION], my testing with kernel 3.10 was mostly to see just how similar S5P6442 is to S5PV210. As I suspected, at least from a code point of view they are very similar. Not identical, because a S5PV210 kernel doesn't work at all, but they are similar. The main differences lie with that CPU, the GPU, and physical addresses and interrupts. The rest is mostly the same.

Also do you know if Samsung ever released the SMDK6442 to the public?
[Galaxy 3 Android Development] tom3q:
Well, for me S5P6442 is still a mix of S3C6410 and S5PV210. It has memory map very close to S5P6450, interrupt layout nearly identical to S5PV210 and set of IP blocks similar to S3C6410 (ARM1176JZF-s, FIMG-3DSE, MFC v1). This is something that device tree would handle very well, as you can simply specify which parts are from which already supported SoC and get something working pretty quickly. Of course there would be still a problem with all those drivers that either do not exist in mainline or exist, but are in rather bad state, but at least you wouldn't have to concentrate on SoC support, but instead could move on with driver porting.

Well, S5P6442 and the whole S5P64xx series is a big mystery to me. I haven't seen neither any development board for it nor any documentation for any of those SoCs. Another thing is that SMDK boards aren't usually available to end users, but rather for bigger customers.
[Galaxy 3 Android Development] m1trand1r:
Thank you both [MENTION=4117753]tom3q[/MENTION] and [MENTION=3633911]hillbeast[/MENTION] for deeper explanation of all this....which is (Being honest) a great mistery for me....but anyway.. [MENTION=2376110]dorimanx[/MENTION] is now mentioned and he'll come here(I hope) to say something about this as you guys really do a lot of code digesting and understanding....and that's not easy ....:)

Thanks for your time you putted into this and i'm sorry if I went too much OT with all this:angel:

Regards :)
[Galaxy 3 Android Development] hillbeast:
Yeah the biggest problem I've found is that even in kernel 2.6.39, the latest kernel which had support for the 6442, the support doesn't seem to be all there. Its unfortunately the cleanest implementation of the code I've found to date, but its also missing significant amounts of code, probably leading to why it was removed.
[Galaxy 3 Android Development] moikop:
Anyone's got any idea why mount would not mount any MTD partition? claims invalid argument...

mount: mounting /dev/block/mtdblock1 on /system failed: Invalid argument

However, I can't see what's wrong.. guess I'm too rusty :S
[Galaxy 3 Android Development] hillbeast:
You made an MTD filesystem on that partition? I think you need to do something along the lines of making an MTD image, then dumping the image using the mtd tools, then mount it. I don't know how to format an MTD partition right on the NAND.
[Galaxy 3 Android Development] moikop:
I flashed CM7A9 MTD, so yes, when I flashed it it created an MTD partition.

If I flash marcellusbe's kernel it works like a charm. So I took it's initfs and same mtd kernel config, but I keep getting that error.

Also, I can flash kernels via dd to mtdblock0 (just info that may be useful).
[Galaxy 3 Android Development] hillbeast:
Okay well I'm not sure. It is probably related to other functions on the kernel not working right like /dev/random etc. There was a lot broken that I never could figure out.
[Galaxy 3 Android Development] moikop:
I don't think there's a problem with /dev/random, (I don't know if I got it right), but for what I've read, it's not showing anything because it has no entropy to work with (or something like that). I rely on the fact that /dev/urandom works.

Think I found the issue, yaffs2 support is broken. I'm patching it up right now, let's see how that turns out...

Thanks hillbeast!

Edit: (I know this will sound stupid, but did we just copy the MTD folder from samsung's kernel? yaffs has references to functions that were remove long ago :S)

Edit: Finished patching it up (not pretty but it's kinda working), now we get:

[ 4.534914] init: processing action 0x26e68 (fs)
[ 4.539869] init: mtd partition 0, boot
[ 4.543575] init: mtd partition 1, system
[ 4.547617] init: mtd partition 2, userdata
[ 4.551846] init: mtd partition 3, cache
[ 4.555811] init: mtd partition 4, efs
[ 4.559524] init: mtd partition 5, reservoir
[ 4.563926] init: mtd partition 6, dgs
[ 4.567717] init: mtd partition 7, param
[ 4.571872] yaffs: dev is 32505857 name is "mtdblock1" rw
[ 4.577124] yaffs: passed flags ""
[ 4.604581] onenand_wait: ECC error = 0x0001
[ 9.575727] init: command 'mount' r=0
[ 9.575983] yaffs: dev is 32505858 name is "mtdblock2" rw
[ 9.579197] yaffs: passed flags ""
[ 13.335074] init: command 'mount' r=0
[ 13.335422] yaffs: dev is 32505859 name is "mtdblock3" rw
[ 13.338546] yaffs: passed flags ""
[ 13.403885] init: command 'mount' r=0
[ 13.403973] init: processing action 0x26f20 (post-fs)

mount output:

/system # mount
rootfs on / type rootfs (ro,relatime)
tmpfs on /dev type tmpfs (rw,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)
tmpfs on /mnt/obb type tmpfs (rw,relatime,mode=755,gid=1000)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
/dev/block/mtdblock1 on /system type yaffs2 (rw,relatime)
/dev/block/mtdblock2 on /data type yaffs2 (rw,nosuid,nodev,relatime)
/dev/block/mtdblock3 on /cache type yaffs2 (rw,nosuid,nodev,relatime)

However, when you ls system or data, it only shows lost+found folder. Maybe related to "onenand_wait: ECC error = 0x0001" (only happens the first time you try to mount it)?

Edit: Sorry for editing this post so many times, I guess it helps me through my thought process :P

I had written a file during first boot, and in the second it stayed there with it's text untouched, and no error this time.. but my partitions are all wiped from that first boot for some reason..

Edit: To sum up, confirmed bug: when changing from marcellusbe's mtd kernel to 3.4, all mounted mtd partitions get formated after claiming "onenand_wait: ECC error = 0x0001". This only happens when changing kernels. Any ideas?

I Will cleaned up the yaffs patch, and updated the repo by tomorrow, just in case anyone's still hanging on to this.
[Galaxy 3 Android Development] hillbeast:
Most likely the partition layout isn't quite the same, or the handling of the hardware isn't quite the same.
[Galaxy 3 Android Development] experiment322:
Are devs still working on this kernel?
[Galaxy 3 Android Development] moikop:
[MENTION=3404423]marcellusbe[/MENTION] [MENTION=4117753]tom3q[/MENTION] maybe you guys can check this out?

Edit: Checked partition layout, there's only a discrepancy in /cache and /efs (would that make it format all the partitions? :S)

In marcellusbe's kernel:

0x00001b800000-0x0000[B]1dd[/B]00000 : "cache"
0x0000[B]1dd[/B]00000-0x00001f500000 : "efs"

3.4:

[ 4.100622] 0x00001b800000-0x0000[B]1de[/B]00000 : "cache"
[ 4.105243] 0x0000[B]1de[/B]00000-0x00001f500000 : "efs"

And the error I mentioned ("onenand_wait: ECC error = 0x0001"), also happens only every boot in marcellusbe's kernel (without wiping the partitions, so I guess we can rule that out as the cause)

Edit: No, the "partition size discrepancy" wasn't the issue causing the wiping when changing kernels... Now I've got nothing :/
[Galaxy 3 Android Development] hillbeast:
I'm confused as well by it. The only other thing I can think of is incompatible versions of the filesystem? I don't know if that happens on Linux but for example if you formatted a drive as NTFS on Windows XP it wouldn't work on Windows NT and it would need reformatting. I don't know if that would happen with YAFFS2. Really though I thought we were going to use UBIFS as its superior in every aspect. Use a single large partition and then split it into smaller UBIFS partitions inside that.
[Galaxy 3 Android Development] moikop:
Well, guess that must be the problem. A weird one, but guess it's not the weirdest thing I've seen.

I went back a couple of pages in this thread and I saw you "complaining" about ubi (thought you had already tried), so I though I'd take the other way (the one marcell had already taken successfully).

I'm a little "confused" by ubi, but I guess I'lll give it a shot anyway...

EDIT:

Actually, after reading a lot of docs about ubi and spending a lot of time trying to find/cross-compile mkfs.ubifs for arm (and stop for a minute and thinking about it), I have come to the conclusion that, in order to get ubifs working, we'd have to delete all the partitions, modify the partition layout to unify system, data and cache (at least, we could leave the others untouched. However, this is something I'm not confident enough to do by myself), and deal with create the ubifs images, partitions, etc.. And after all that, we would be in the same spot as now: with an empty (but working) /system partition. And yaffs2 is working normally (you know, skipping the "wipe with first boot" thing). So I'll just re-install cm7mtd with the 3.4 kernel, try to avoid flashing the original kernel and go on to something else. It's not like we're using ext4 like we used to do, now we have a *proper* fs working. IMHO, we can deal with UBIFS later on if needed at all.

BTW, not sure what to do next, tried to boot android (Yes, you guessed right! It's not working :P), and did an strace on /init to see why it crashes. Here's a link (https://www.dropbox.com/s/arodqihgntk08al/strace.log).

I haven't even locked at it yet, it's really late and tomorrow I need to wake up really early (bad combination). If you get a chance to check it out let me know.
[Galaxy 3 Android Development] swiftgeek:
Is this attempt going to use device tree? (so it could be mainlined, at least in theory, in case of succeeding)

I'm interested in having archlinux/mer on this phone¹ with efl/enlightenment (probably, not using mtd at all)

It would be also nice to try porting u-boot here (but i need to get versaloon up&running for that… wont happen soon).

BTW has anyone found (all) UARTs on PCB? (And maybe other useful test points)

¹I just need to fix one hw malfunction ~usb and find some copy of 80-VF846-2 (and 80-VM299-2 for other targets if i get lucky)
[Galaxy 3 Android Development] hillbeast:
Looking at the code, device trees appear to be used, however we won't ever get this mainlined. Support from Samsung will be non-existent and it's almost impossible to get anything through the Linux mailing lists.

Also there's no point in trying to get u-boot working. It'll just risk bricking peoples phones. As for the UARTs, we know about the external UART (ttySAC1), but the internal ones are either connected to something already, or they don't have any pads anywhere. Believe me, I went through pretty much everything. It was a very long night.

A while back a I poked at getting it to boot either 3.10 or 3.11 (which was the latest at that time). I ported mostly S5PV210 code and got it booting reasonably far, but never went further than that through lack of motivation, but once I get my new computer (should be by the end of January), I might take a look at Android development again.

If you are able to get Debian booting, then we might be able to try again getting AOSP to boot. I believe there must have been a bug in the kernel somewhere that prevented it booting which probably doesn't exist in this code.
[Galaxy 3 Android Development] swiftgeek:
As long as one has jtag - there is no risk involved (boot from JTAG is obviously first step). Also whole point of porting u-boot is to enable quicker dev. and maybe give some unbreakability means (That would actually require neat hax before u-boot, like omap people do). Also it would play better with linux distributions. I know that lots of people from here like AOSP, but please, with this memory constraint it's about time to consider alternatives.

As for the UARTs - i just need to get ( all ) TX signals for starters so it will be easier.

The only samsung support i could possible want is from enlightenment project, and pushing stuff to mainline is only extremely hard and time consuming task with mostly positive effect on code quality (in present time)… also somebody has to use this device at all :)

And I'm aware of QSC6270 being completely locked, which wont stop me from trying.