yashsingh1/xdaforums huggingface dataset:
[Galaxy 3 Android Development] tom3q:
This is just a single pin in single bank, which does not mean that all banks are correctly defined. I don't say that they aren't (in fact I didn't have time to look at the code yet), but it's not a test that proves anything in general. (But maybe I didn't understand what it was intended for?)

An example of more correct methodology would be to dump all GPIO registers from a running old kernel using, for example, /dev/mem, then do the same on new kernel and then finally compare register values (with some margin taken for possibly runtime reconfiguration done by running drivers).
[Galaxy 3 Android Development] hillbeast:
Well I'm looking mainly at GPIOs that are in the middle of all of them. The way it calculates the addresses and registers for each of the pins is additive so if its still working fine in the middle and behaving as I expect, I'm pretty sure its working. I'm not trying to confirm the whole system works, just that I am using the right methods for configuring the pins. I'm getting the keypad to work at the moment as a final test before I get on to I2C. I'll work on it more once I get home.

I have until Tuesday to make good progress because that's when my ODROID will arrive and most likely the Galaxy 3 will be a victim of "new device is cool" syndrome.
[Galaxy 3 Android Development] andreapier:
Hillbeast, great work!

I'd really like to see this thing to run in top of my G3!!

Thanks man!
[Galaxy 3 Android Development] m1trand1r:
^^^now this is OT...:D:D:p...

Sent fom my S-II running CM-10 by mcm811 powered with DorimanX kernel 7.37
[Galaxy 3 Android Development] Arjav23:
This is a nooby question

Will this kernel help is resolving the camcorder bug in cm roms

And hillbeast, you are doing an awesome job.:thumbup::thumbup::thumbup::thumbup:
[Galaxy 3 Android Development] moikop:
@arjav23:

there's still a lot of work to do until this kernel will be useful for "something", so that question is not important right now. We'll look into it in proper time.

btw, hb: In 8 days aprox I'll be back home. Can't tell you how much I want to get back at this project. Good work!
[Galaxy 3 Android Development] hillbeast:
Okay great. I was hoping you'd still be keen to develop this with me. I'm trying to wrap my head around the GPIO IRQ stuff at the moment, but I'm tired at the moment so none of it is sticking and I'm lacking motivation. Might take another look tomorrow night. I won't commit my current changes as it's messy right now.
[Galaxy 3 Android Development] hillbeast:
I ran a few more tests last night with the buttons/keypad/GPIO and I can poll the GPIOs to see buttons being pressed on the keypad (well every button except home and power as I can't find the GPIO for them right now), and they're working, but I can't get gpio-keys to work because it's looking for the interrupts for those GPIO pins.

Where would I look to define the IRQs for GPIOs, tom3q?
[Galaxy 3 Android Development] tom3q:
There are two types of interrupts on S5PV210-like SoCs:

- EINTs, which are always mapped into IRQ number space and which have wake-up capability

- GPIO interrupts, which have to be registered in IRQ number space first and don't have wake-up capability

For the former you simply use gpio_to_irq function to get IRQ number of given GPIO pin. For the latter you have to call s5p_register_gpio_interrupt instead, with the same semantics as gpio_to_irq. Resulting IRQ number has to be passed to any interested drivers using resource, platform data or i2c board info, whatever appropriate.

You don't have to care about any setup (like masking/unmasking, trigger setup, etc.) from board code, as this will be requested through generic functions by the interested driver (probably based on information in platform data or resource flags) and handled by GPIO IRQ drivers (see plat-s5p/irq-eint.c and irq-gpioint.c).

You just have to make sure that interrupt capabilities of all GPIO banks are set correctly in drivers/gpio/gpio-samsung.c . I guess that configuration for S5P6442 should look similar to S5PV210, based on other similarities.
[Galaxy 3 Android Development] moikop:
Alright (sorry for off-topic), I just changed my flight's date for 13 more days, so it'll be a while until I get back. Once I'm ready to help with this project I'll get in touch with you.

Greetings to all.
[Galaxy 3 Android Development] hillbeast:
Tada:
[Galaxy 3 Android Development] hillbeast:
And just for fun:

Now I need to get those buttons to work. Also I noticed /dev/random is bugged. It just stops while generating random numbers or something. The device is still alive because the cursor is still flashing on fbcon and such, so I dunno what's wrong with it, but having a screen is great progress, and it means people without UART can now do development.
[Galaxy 3 Android Development] hillbeast:
I'm currently having to go through the gpio and eint code with a fine toothed comb. The fact the I have the screen working, and the fact that I can poll the gpios manually and it will detect input from the buttons there, but it won't read them in the gpio-keys driver tells me something is wrong in there somewhere with the interrupts. The gpio data side of it works flawlessly. Getting the screen working was surprisingly easy. It didn't even need to be recompiled multiple times with me fixing up settings somewhere. I just added the configuration and away it went.

I really want those buttons working before I continue with anything else because they are a simple device to get going and getting them going should mean everything in the gpios are working meaning I can get started on other hardware, specifically I2C and MMC, and once MMC is working I can put an update.zip on the SD card and start trying to boot into Android.

I should also mention I was up until 3:30am last night rewriting the gpio code to bring it more in line with S5PV210. I think when we made it we were assuming it would be similar to S5P64x0 hence why it was such a mess before. I'm completely ignoring those chips now because our GPIOs are the same as S5PV210 (Galaxy S CPU) and our IRQs are the same as well. I just copied and pasted the IRQs from PV and it was fine with it. I need to go through and fix up any other assumptions we made 9 months ago when the phone was in a much less complete state.
[Galaxy 3 Android Development] hillbeast:
After poking around for ages, and even pulling out Microsoft Excel, and several cans of energy drink, many late nights, and much hair lost: buttons are working. About damned time.
[Galaxy 3 Android Development] josip-k:
So much is done for the little G3,great work hillbeast,im kinda jealous,i dont even have 3.4 kernel on my Gnex,this project is really taken my eye :)
[Galaxy 3 Android Development] ilievski.ace:
Wooooow thanks hillbeast For the Hard Work ... it is perfect to hear that the buttons are Working :)
[Galaxy 3 Android Development] hillbeast:
It gets better. Clock is now working too. Just want that MMC to work now. The clock working though comes from the MAX8998 controller meaning I2C is working as well. It also means I have regulator controls for the CPU voltage and all that other stuff most likely.

It's so nice looking at clean code in mach-apollo rather than that garbage that Samsung left us.
[Galaxy 3 Android Development] Stanislaus:
Does this mean that kernel 3.4.x is almost finish?
[Galaxy 3 Android Development] hillbeast:
No, but it does mean that it's getting close to being able to at least boot Android. If the SD card was working, recovery is fully working.
[Galaxy 3 Android Development] protomank:
Can't get tired of pressing the thanks button! Your work is amazing hillbeast, and I thank you from the bottom of my heart. I know the felling you are talking about (then I was able to code a green rectangle on my PS2 was the same deal), and I got also exited when seeing your pictures, lots and lots of work paying off.

Nice to know that finnally we are finding out more about our hardware internals, and getting signals, IRQs and other, similar or idential to Galaxy S is really a big luck, as this hardware received a lot of attention from devs, so info is abundant.

I wish you the best luck and now, all the devs rally together to help out get android booting please! :D
[Galaxy 3 Android Development] coolfire92:
@Hillbeast

Nice progress!

Will cm7 have to be rebuild with support for kernel v3.x?

Gingerbread was announced when v3 didn't exist.As i recall only after ICS android was built around kernel v3.

Maybe ICS will boot?

Question:Will android boot without drivers? If i am not mistaken that hasn't been done.
[Galaxy 3 Android Development] josip-k:
Well galaxy s has 3.x kernel for gingerbread also,so i think it should work
[Galaxy 3 Android Development] hillbeast:
Homebrew? On what?

Also the baseband will most likely be whatever the latest modem is.
[Galaxy 3 Android Development] D@rekills4:
Noob Alert!

Baseband is the modem.bin provided by Samsung right?
[Galaxy 3 Android Development] hillbeast:
Yes. There are different versions of it and nobody knows what changes specifically in them, all we know is some work better for others and others don't work so nicely.
[Galaxy 3 Android Development] raja4sure:
had a talk with dharam and he said he'll help you in manner he can......so just get in touch with him....i think he can also be a dev in this port although he doesn't have a G3 anymore .......

Also Tom3q said that when he gets time he'll try to reuse his codes for spica on g3....
[Galaxy 3 Android Development] hillbeast:
Thanks for the info. I shall contact all the developers to get their attention, as they may not see this thread, but I'll probably do that later as it is getting late.

If someone wishes to point them here then feel free to do so.

Also question to the other developers, with the mach code, I have three options:

1: continue to take the code from the old kernel and fix references (time consuming and may lead to issues later down the road)

2: adapt the code for another mach (s3c64xx or s5p-64x0) (may or may not work as we don't know how similar our chipset is to these other ones - it could be close or it could be completely different... thanks Samsung for giving us informations...)

3: make new code from scratch (I wouldn't have a clue how to do that)

Which do you reckon is the best course of action?
[Galaxy 3 Android Development] tom3q:
Well, I wouldn't even take seriously option 1. There is no point in using the same poor code and just updating rest of the kernel (version doesn't really matter). First, this would copy all the problems of original kernel to new one. Second, this will add much more work with fixing all the problems with porting the old code to new code base and possibly create even more problems than the original kernel had. So this is likely to be just a waste of time.

Option 3 also adds unnecessary work, as there is already pretty good support of S5P series SoCs in the mainline, so there is no need to rewrite this from scratch.

IMHO the only reasonable option is option 2, i.e. using latest mainline as code base (android-3.4 branch of android/kernel-common is a good candidate), while extending s5p64x0 with support for s5p6442 (according to Samsung website all the models from S5P64xx line are compatible, except differences in peripheral set of course), using original kernel as a reference how the hardware is arranged (registers, memory map, some specific tricks and workarounds for hardware bugs and, what's most important, board-specific configuration, like GPIOs, EINTs, voltage regulator settings, etc.) and trying to reuse as much as possible from my spica-3.0 sources (e.g. battery driver, s5k4ca camera sensor driver and most probably several others).
[Galaxy 3 Android Development] D@rekills4:
The modem from European firmwares cause problems to most of Vodafone users in India....

We need to flash the modem.bin of I5801DDJP2/6 firmware everytime we flash any ROM without this modem (at this point 99% of them).

Could you use this?

http://xdaforums.com/showthread.php?t=1413610

Also, it would be nice if a few non-indian users would try this baseband if they have any problems if hillbeast plans to use it.
[Galaxy 3 Android Development] moikop:
I completely agree with Tom3q on this one.
[Galaxy 3 Android Development] josip-k:
Id be so glad if i could just buy and send an x8 to tom3q/hillbeast to improove our phones...:)
[Galaxy 3 Android Development] CroNk3r:
It would be better for you just to take back your galaxy 3....:D
[Galaxy 3 Android Development] josip-k:
X8 is a little better...
[Galaxy 3 Android Development] hillbeast:
Okay I have scrapped all the current work on option 1 and switched to option 2. I was realising it after I started that this was going to be problems.

At least I didn't get too far into it.

Well this is a G3 forum so...
[Galaxy 3 Android Development] headers.chennai:
Noob Ques: Are we not supposed to look at chipset similarity before starting tweaks? :confused:
[Galaxy 3 Android Development] hillbeast:
The problem we have is that Samsung never officially released a datasheet for the S5P6442 and as a result we don't have any information we can go by when we work with it. We have to go by trial and error, debugging the old kernel, or reading the old source code.
[Galaxy 3 Android Development] Spitlebug:
Given that this is an older phone, would they release that if we begged them?

I know they want to sell new phones, but I hardly think that a few older phones isn't going to kill their already huge market share.
[Galaxy 3 Android Development] hillbeast:
Considering they haven't released it when we asked ages ago and don't reply to communications, I'd say its never going to happen. I wouldn't be surprised if the documents don't exist anymore.
[Galaxy 3 Android Development] cdesai:
Yea, they removed all the links to s5p6442 from their site ages ago.

http://www.samsung.com/global/busin...archType=PARAMETRIC_SEARCH&iaId=835&parameter[0][parameterId]=242&parameter[0][specValue]=ARM%2011%20Series%20(1176)

No s5p6442, only s3c6410, and s5p64x0

EDIT : Found some interesting info here

http://lists.infradead.org/pipermail/linux-arm-kernel/2009-August/000156.html
[Galaxy 3 Android Development] eeshlikhith:
well hes talking about linux kernel code and our chipset AND he is from samsung. What if we contact him? Perhaps we could get some help from him? His email is mentioned at the end of the post too..
[Galaxy 3 Android Development] hillbeast:
With reading that, I'm now facing the choice, do I use s5p64x0 as the base or do I use s5pc110 which the guy says is closer to our SoC. What do you guys reckon?
[Galaxy 3 Android Development] tom3q:
I'd still say that s5p6442 should be almost identical to other SoCs from s5p64x0 family, but I'll try to look into it today, by comparing sources of s5pcxxx and s5p64x0 from mainline and s5p6442 from G3 kernel.
[Galaxy 3 Android Development] balamu96m:
My thoughts......

As far as i read from a website, think the error lies here:

I/DEBUG ( 138): signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr aca17600

and here

I/DEBUG ( 138): #00 pc 00017600 /system/lib/libdvm.so
I/DEBUG ( 138): #01 pc 000114cc /system/lib/libc.so (pthread_mutex_unlock)

Also, google took me to a page at modaco from where it seems that the above mentioned error lies in the lib files that prevents the phone from booting.

More info/Source: http://www.modaco.com/topic/351723-devexperimentalrom-ideos-x3-gingerbread-rom-runs-on-pulse/page__st__40#entry1904951

So,

if (it is the error)

{

how to solve it ??

}

else

{

what could be the error ??

}

BTW, cheers for the successful journey so far & thanks for your hard work !! :victory:

EDIT:

Could it also be because its a BML version ?? i believe marcel hasn't released his MTD version & could it be because of that ??
[Galaxy 3 Android Development] android-turk:
Maybe cm7 needs a modification to start working with kernel 3.4.x but i'm not a developer just saying my theorie about what could be the problem

:)
[Galaxy 3 Android Development] twinky444:
If OPENfimg is implemented to your 3.0 kernel, CM7 alpha 8 and up will probably be able to boot, because it uses OPENfimg instead of samsung's FIMG drivers.

At least I think OPENfimg has to be implemented to the kernel itself... Maybe its not booting because of samsung's fimg drivers used in alpha 7? Another possible theory.

I know when I tried to switch back to fimg drivers on CM7 a8, I couldn't boot because replacing just lib files didn't work. It has something to do with the kernel, too, I think.

Hope this helps. Good luck!
[Galaxy 3 Android Development] aarrun:
maybe trying ICS or JB on this kernle wud help, instead of trying cm7 to boot on it...... its just an idea plz dont sue me if wat i said is noob :P
[Galaxy 3 Android Development] moikop:
I'm not an expert on reading this kind of dumps either, but I don't think the " I/DEBUG ( 138): cannot get registers: I/O error" is the error itself but rather just a secondary problem (maybe it just tried to access something it couldn't while making the log?). I'll keep thinking of something, but probably I won't be useful until I get back home.
[Galaxy 3 Android Development] hillbeast:
Yeah reading through other peoples ideas and also rereading the log I don't think it's the error. I'm pretty sure the actual error is ILLOPC which is illegal opcode. I'm not 100% but that as far as I'm aware means there's an instruction that's trying to be executed that the processor can't understand. There's also an error above it (Illegal Instruction) that tells me that too. I'm confused by that though because the code was compiled for ARMv6 before (heck it used to run on this phone) so I'm not sure what instruction it can't understand, which leaves me with a few ideas of what's wrong:

At the start of the log, the kernel is saying ARMv7, and somehow Android is trying to run through ARMv7 instructions?

The kernel is missing some library or driver or function that Android wants

I'll look into that first point for starters to see what that's all about.

EDIT:

From arch/arm/kernel/setup.c:

printk("CPU: %s [%08x] revision %d (ARMv%s), cr=%08lx\n",
cpu_name, read_cpuid_id(), read_cpuid_id() & 15,
proc_arch[cpu_architecture()], cr_alignment);

So if we make that easier to read:

printk("CPU: %cpu_name [%read_cpuid_id] revision %read_cpuid_id&15 (ARMv%proc_arch[cpu_architecture]), cr=%cr_alignment\n");

So proc_arch[cpu_architecture] is our problem there.

EDIT 2:

Oh I see:

Kernel 2.6.32 code:

#ifdef CONFIG_CPU_V6
/* This patch is to detect CPU arch for ARM1176JZF-S.
* The ARM1176JZF-S has VMSAv7 memory model(same as cortex)
* but it is not the ARMv7 architecture.
*/
return CPU_ARCH_ARMv6;
#else
unsigned int mmfr0;

/* Revised CPUID format. Read the Memory Model Feature
* Register 0 and check for VMSAv7 or PMSAv7 */
asm("mrc	p15, 0, %0, c0, c1, 4"
: "=r" (mmfr0));
if ((mmfr0 & 0x0000000f) == 0x00000003 ||
(mmfr0 & 0x000000f0) == 0x00000030)
cpu_arch = CPU_ARCH_ARMv7;
else if ((mmfr0 & 0x0000000f) == 0x00000002 ||
(mmfr0 & 0x000000f0) == 0x00000020)
cpu_arch = CPU_ARCH_ARMv6;
else
cpu_arch = CPU_ARCH_UNKNOWN;
#endif

Kernel 3.4.5 code:

unsigned int mmfr0;

/* Revised CPUID format. Read the Memory Model Feature
* Register 0 and check for VMSAv7 or PMSAv7 */
asm("mrc	p15, 0, %0, c0, c1, 4"
: "=r" (mmfr0));
if ((mmfr0 & 0x0000000f) >= 0x00000003 ||
(mmfr0 & 0x000000f0) >= 0x00000030)
cpu_arch = CPU_ARCH_ARMv7;
else if ((mmfr0 & 0x0000000f) == 0x00000002 ||
(mmfr0 & 0x000000f0) == 0x00000020)
cpu_arch = CPU_ARCH_ARMv6;
else
cpu_arch = CPU_ARCH_UNKNOWN;

So ARMv6 chips don't detect right and need that thing to force them?
[Galaxy 3 Android Development] hillbeast:
Figured it out. Was the floating point emulation. I was using NWFPE because it was at the top of the list, but the old kernel uses VFP. I switched to VFP and now I get a different error. Haven't even read it yet:

--------- beginning of /dev/log/main
I/cm ( 98): Welcome to Android 2.3.7 / CyanogenMod-7.1.0-GT-I5800-KANG
I/cm ( 99): _
I/cm ( 100): __ __ _ ___ _ _ __ ___ __ _ _ _ _ __ __))
I/cm ( 101): ((_ \(/'((_( ((\( ((_)((_( (('((\( ((`1( ((_)((_(
I/cm ( 102): )) _))
I/cm ( 103):
I//system/xbin/run-parts( 93): mount: mounting /data/local/download on /cache/download failed: No such file or directory
I/logwrapper( 93): /system/xbin/run-parts terminated by exit(0)
I/DEBUG ( 137): debuggerd: Dec 25 2011 06:31:08
I/Netd ( 136): Netd 1.0 starting
--------- beginning of /dev/log/system
I/Vold ( 135): Vold 2.1 (the revenge) firing up
D/Vold ( 135): Volume sdcard state changing -1 (Initializing) -> 0 (No-Media)
W/Vold ( 135): No UMS switch available
D/AndroidRuntime( 156):
D/AndroidRuntime( 156): >>>>>> AndroidRuntime START com.android.internal.os.ZygoteInit <<<<<<
I/AndroidRuntime( 156): Heap size: -Xmx32m
D/AndroidRuntime( 156): CheckJNI is OFF
D/AndroidRuntime( 185):
D/AndroidRuntime( 185): >>>>>> AndroidRuntime START com.android.internal.os.ZygoteInit <<<<<<
I/AndroidRuntime( 185): Heap size: -Xmx32m
D/AndroidRuntime( 185): CheckJNI is OFF
I/SamplingProfilerIntegration( 185): Profiler is disabled.
I/Zygote ( 185): Preloading classes...
E/Zygote ( 185): setreuid() failed. errno: 2
D/dalvikvm( 185): GC_EXPLICIT freed 48K, 77% free 239K/1024K, external 0K/0K, paused 3ms
I/bluetooth_ScoSocket.cpp( 185): Entry name = MY-CAR ScoTypes = 0x7f
I/bluetooth_ScoSocket.cpp( 185): Entry name = Motorola HF850 ScoTypes = 0x7
D/AndroidRuntime( 191):
D/AndroidRuntime( 191): >>>>>> AndroidRuntime START com.android.internal.os.ZygoteInit <<<<<<
I/AndroidRuntime( 191): Heap size: -Xmx32m
D/AndroidRuntime( 191): CheckJNI is OFF
I/SamplingProfilerIntegration( 191): Profiler is disabled.
I/Zygote ( 191): Preloading classes...
D/dalvikvm( 191): GC_EXPLICIT freed 47K, 77% free 237K/1024K, external 0K/0K, paused 4ms
I/bluetooth_ScoSocket.cpp( 191): Entry name = MY-CAR ScoTypes = 0x7f
I/bluetooth_ScoSocket.cpp( 191): Entry name = Motorola HF850 ScoTypes = 0x7
D/dalvikvm( 191): GC_FOR_MALLOC freed 2943K, 58% free 2180K/5123K, external 0K/0K, paused 77ms
[ 22.102816] init: untracked pid 191 exited
D/AndroidRuntime( 198):
D/AndroidRuntime( 198): >>>>>> AndroidRuntime START com.android.internal.os.ZygoteInit <<<<<<
I/AndroidRuntime( 198): Heap size: -Xmx32m
D/AndroidRuntime( 198): CheckJNI is OFF
I/SamplingProfilerIntegration( 198): Profiler is disabled.
I/Zygote ( 198): Preloading classes...
D/dalvikvm( 198): GC_EXPLICIT freed 47K, 77% free 237K/1024K, external 0K/0K, paused 4ms
I/bluetooth_ScoSocket.cpp( 198): Entry name = MY-CAR ScoTypes = 0x7f
I/bluetooth_ScoSocket.cpp( 198): Entry name = Motorola HF850 ScoTypes = 0x7
D/dalvikvm( 198): GC_FOR_MALLOC freed 2941K, 58% free 2181K/5123K, external 0K/0K, paused 76ms

No clue what it means.
[Galaxy 3 Android Development] raja4sure:
I don't know everything..but as compared to the Booting CM7 logs there are some differences AFAIK.

I/logwrapper( 93): /system/xbin/run-parts terminated by exit(0)

it should be

run-parts: /system/etc/init.d/01sysctl exited with code 1

and the Zygote is not successfully loading up as you can see its trying to start in again and again thats why i guess ServiceManager is not able to start.. correct me if i am wrong..
[Galaxy 3 Android Development] detlef25:
I think you're on the right track raja4sure. The line

looks like it is trying to bind-mount /data/local/download to /cache/download, which is failing, in turn causing run-parts to exit prematurely. Hillbeast, could you try to create the folder /data/local/download? Or otherwise check run-parts or fstab for the string and just comment the line out.

Another possible explanation could be that it is running out of memory while preloading all classes. This should result in an OOM though. Is there anything exciting happening in the kernel log or console at the time?
[Galaxy 3 Android Development] hillbeast:
I'll take a look into that.

And what you're seeing is output from UART. Anything the kernel has to say is merged into the logs.

On another note, I just noticed Google haven't bothered updating their 3.4 branch in ages. Linux is now on 3.4.27 and they're still on 3.4.5. I was wondering why the version number hasn't gone anywhere in a while. Anyway, I merged in the kernel.org repository and now we're working with 3.4.27.

I'll update the first page as well so it's got the latest UART log.