Folks, I’m giving up.
This hardware is just unusable.
This tablet is only usable, when you’re using it in a cold storage house under GNU/Linux.
Because of the hardware bugs every system using multi threading only boots once, when the tablet has been lying around for some days at a cold place (like let’s say in the wine cellar)
After having been warmed up a bit, it randomly freezes somewhere in the boot process which leads to funny things like a half built up login screen…
Can’t these people read the design guide lines and data sheets before they start wildly connecting some wires and give a PCB into production?
Also this TEGRA2 chip is already a unusable piece of crap.
And people buy this crap…
Can’t we just get rid of all companies producing SoCs except Texas Instruments and can’t TI do their smart phones them self by the way?
Would make the hardware market grow rapidly in quality… >.>

Texas Instruments is obviously the only company producing usable SoCs ATM

• Good documentation
• Works as expected
• Nearly NO ASIC-errors (There are some like the battery bug in OMAP35xx)

Samsung Galaxy S2 and Asus Transformer Prime, both with Android market…
I don’t pay for software, I’m FOSS user…

WTF? Money for installing packages?
My solution for such an issue is easy.

If it costs, don’t use it 🙂

And again, increasing recursive Googling…

(3) ...however, if you have a stock eglibc
and a kernel with the erratum workaround disabled/removed,
then things seem in practice to work OK.
Speculation is that perhaps the erratum is only
a problem in marginal situations (eg if the core is very hot).

Ok, wtf. “marginal situations”?
Does that mean, the hardware has the freedom to not execute the code in cases where it hates the user, like in my case? >_>

Seriously, the core hasn’t reached high temperatures yet, but still shows sign of this bug.
Ok, cancel sign: a system where already /sbin/init segfaults is not a sign, it’s more like “no discussion”

https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/739374

Anyway. I’ve now made a portage overlay for eglibc and am cross-compiling eglibc-2.15 in this very moment.
Let’s see if switching Gentoo to eglibc solves my problems…

BTW: The overlay can be found under:
https://gitorious.org/o2s-gentoo/eglibc-overlay/trees/master

Didn’t everyone already dream of that?
Ok… Not everyone, just the hardcore nerds and hackers like me, who aren’t only using bleeding edge software but more or less blood dropping flesh wound software (yes, sometimes even -9999- ebuilds in Gentoo >_< )

I guess BenBee asked me some time ago, if this would be possible…

Yes it is
./kdetect.sh
and
./autokernconf.sh

Should do the trick.
Go to the following source: http://cateee.net/autokernconf/

Howdy
A friend of mine owns a “Samsung Galaxy S2”
CPU-info tells us there is a SMDKV310 SoC in it:

# cat /proc/cpuinfo
Processor       : ARMv7 Processor rev 1 (v7l)
processor       : 0
BogoMIPS: 1592.52

Features: swp half thumb fastmult vfp edsp neon vfpv3
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x2
CPU part: 0xc09
CPU revision    : 1

Hardware: SMDKV310
 Revision: 000e
 Serial  : 304d19f743777c9e

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/arm/mach-exynos/mach-smdkv310.c;h=83b91fa777c1aeb4ca5ee95ff81f244a1641e904;hb=HEAD

Looks as there would be support for it in upstream.
Let’s see if it boots as well. ( e.g. upstream support for tegra2 is just formalism, the code in master doesn’t do anything useful)

Hi Folks

I stumbled across the following link right now:
http://androidroot.mobi/technical/tf-secure-boot-key/

In my opinion this kind of sealing up a device is an unacceptable measurement.
I suggest you check if there is such a security measurement documented and if it is boycott the respective producer.

ha! with backlight working! 😉

localhost ~ # uname -a
Linux localhost 3.1.10-00008-g03975b1-dirty #106 SMP PREEMPT Wed Apr 11 12:43:53 CEST 2012 armv7l ARMv7 Processor rev 0 (v7l) adam GNU/Linux