**** BEGIN LOGGING AT Sat Mar 10 02:59:58 2012 Mar 10 03:00:57 Anybody there? Mar 10 03:06:51 Hello. Mar 10 03:07:46 I'm new to this project, and only here to see whats up.... But as you requested, I do fall into the category of `anyone'. I also do not know enough to point you in the right direction for your question, sorry. Mar 10 03:07:52 But I am anybody! Mar 10 03:29:00 Well, that somewhat works. Mar 10 03:29:17 It is an answer to something. Mar 10 03:29:22 Glad to help! Mar 10 03:29:51 So your cross-compiled kernels, how nowhere are they getting? Mar 10 03:30:10 The AT&T boot logo stays there. Mar 10 03:30:45 So it's never actually attempting to initialize the graphics. I can't tell if it does anything else, but it never boots. Mar 10 03:31:42 The config was actually taken from a /proc/config.gz from a kernel that was operating on the phone itself. Mar 10 03:33:55 Hmmm, I don't know enough to really be of any help, but my first thought is ``is the boot loader seeing the image? does the boot loader know what kernel to load?'' Mar 10 03:34:24 It's not like x86, you don't get any visibility into that. Mar 10 03:34:49 You just flash to the partition that it is supposed to go to. Mar 10 03:34:59 hmmm Mar 10 03:35:12 That doesnt soudn right, even ARM and other things still have bootloaders. Mar 10 03:35:18 Or Heimdall, the program that interfaces with the Samsung download firmware does. Mar 10 03:35:25 I dont care what system it is, it has something, and that something bootstraps you up to an OS Mar 10 03:35:44 Yes, it does. It's just not visible to the user. Mar 10 03:36:01 Indeed, do you have to flash a custom bootloader or modified version to load 3rd party kenrels and such? Mar 10 03:36:15 I had to get SHR running on my n900. Mar 10 03:36:39 *I had to, to get... Mar 10 03:37:11 Yes and no. The AT&T one will work normally with the partition map they use, but one is put in place by the Cyanogenmod stuff to use the MTD partition scheme instead. Mar 10 03:37:53 Thing is, it's supposed to boot whatever is on that partition. Mar 10 03:38:21 Of course if there is something that has to be done in addition to just the zImage, I don't know what it is. Mar 10 03:38:36 I don't believe it uses uBoot or anything so common. Mar 10 03:39:07 uBoot seems to be the best >.> Mar 10 03:40:41 It does make sense and it is easy to use. Mar 10 03:41:53 Of course it doesn't keep the ARM graphics situation from being a pain. Mar 10 03:46:43 Anyway, if you use uBoot and then run file under Linux, it determines that it's uBoot and gives the configuration parameters. The kernels used on this phone for Android that operate just show up as data. Like regular zImage kernels and unrecognized data files are. Mar 10 03:50:19 * nully_ nods Mar 10 04:16:39 What surprises me is that if the Noveau guys can come up with such great drivers for desktop NVIDIA cards, how come no-one has tried the same thing for ARM GPUs like Snapdragon, PowerVR or Tegra? Mar 10 04:19:52 Well NVidia gives stuff for Tegra 2, but its closed and doesnt seem to operate all that well. Mar 10 04:20:34 thats what I mean, the GPU vendors in the ARM space are all closed Mar 10 04:20:38 PowerVR is a pain since they insist on keeping it closed and making people sign up to the manufacturer's site for it. Mar 10 04:21:01 At least there's a reverse engineered version for Mali 200 and 400 now. Mar 10 04:21:04 usually a closed user-space driver combined with a small kernel driver to shift commands from the closed user-space driver to the hardware Mar 10 04:21:14 Yeah but Mali isn't in that many devices Mar 10 04:21:27 But the T604 is the first that is going to be OpenCL capable. Mar 10 04:21:37 Hence the need to tackle the bigger platforms like Tegra and PowerVR Mar 10 04:22:01 Yeah. I think NVidia is just still working on the Tegra stuff. Mar 10 04:22:04 Sort of. Mar 10 04:22:22 My guess is that there just aren't enough people with the right skills and the interest in reverse engineering ARM GPUs Mar 10 04:22:34 if I had the skills, I would tackle the GPU in my N900 :) Mar 10 04:22:47 but my ARM skills are minimal :( Mar 10 04:23:14 and my kernel knowledge non-existant Mar 10 04:23:26 See, Tegra 4 is supposed to have OpenGL support asides from EGL GLES2. That means better drivers that won't be compatible with older versions. Mar 10 04:24:13 Tegra isnt the #1 issue anyway, its PowerVR who are in far more devices than all the other ARM GPU vendors combined Mar 10 04:24:29 Well, I've built plenty of x86/x64 kernels, I have built very few ARM kernels that have worked. Mar 10 04:24:40 Come up with open drivers for the PowerVR SGX family and you will make a lot of people very happy :) Mar 10 04:25:10 Well, that's a tall order. Mar 10 04:25:45 If I had hardware and a working set of closed-source drivers, the Intel Atom chips with PowerVR cores would be somewhere I would start Mar 10 04:26:23 The GMA500 have been played with. Mar 10 04:27:36 I cant see GMA500 being any more complex to reverse engineer than a top-of-the-line NVIDIA GPU. I guess its all a matter of more people with the right skills being interested in Noveau than in PowerVR or GMA500 Mar 10 04:28:10 Well, they have much different paths. Mar 10 04:29:07 me wonders what the driver situation on GMA500 is Mar 10 04:29:57 The PowerVR still have far more fixed-function in them. They do not have unified shader engines so they are NVidia 7000 equivalent. Mar 10 04:30:47 Additionally they are tile-based renderers which goes back to the Dreamcast. Mar 10 04:31:14 But they're a pretty cheap IP to be bought and tacked onto an ARM core. Mar 10 04:31:57 I wonder if any of the ARM GPU vendors might one day follow ATI and become more open Mar 10 04:32:07 Opening up the specs seems to have been good for ATI Mar 10 04:32:08 I hope so. Mar 10 04:32:56 Yeah, it has. The Mesa/Gallium drivers have been slow compared to the closed-source drivers, but they've been getting better over time. Mar 10 04:33:54 There's the rumor that because NVidia joined the Linux Foundation that they will do something like that. Mar 10 04:35:13 I am surprised Intel (who clearly doesn't particularly like the closed nature of the PowerVR drivers) hasn't said something like "first company to provide us with a suitable embedded GPU that has 100% open drivers will get their core in and get $BIG_SALES_NUMBER or something. After all, it is in their interests to have open drivers for these chips AND they sell enough ATOM... Mar 10 04:35:14 ...parts that they might be able to get a vendor to listen Mar 10 04:35:35 Then again, maybe even Intel isnt big enough to overcome the in-grained fears of what opening these drivers will mean Mar 10 04:37:05 Intel makes their own graphics IP, they only needed GMA500 because they didn't have something else in the pipeline. Mar 10 04:37:44 actually, Intel have recently announced further chips with PowerVR cores Mar 10 04:38:18 Intel is the biggest player in the Mesa field right now, and they have almost brought it to OGL 3.0. Mar 10 04:38:36 Wait, which ones? The Ivy Bridge stuff isn't. Mar 10 04:40:24 hmmm, Google shows up a bunch of reports for it but its hard to tell whats rumors and unconfirmed information, whats referring to previous ATOMs with PowerVR and what is possibly confirmation that Intel will be using PowerVR in their next lowest-power ATOM core Mar 10 04:42:07 aha Mar 10 04:42:09 http://en.wikipedia.org/wiki/Atom_%28system_on_chip%29 Mar 10 04:42:12 shows they are using PowerVR in Medfield Mar 10 04:43:04 Yeah, that's possible. They have enough trouble with Atom already. Mar 10 04:43:06 which is intended to try and compete with OMAP, Snapdragon, Tegra etc Mar 10 04:43:37 Maintaining all the x86/x64 frontend translation eats up a lot of power. Mar 10 04:44:22 So it's difficult for them to compete. They mostly just try to go to a lower process, and the PowerVR stuff is cheap to pick up and uses little power. Mar 10 04:45:12 I actually wanted to see PowerPC go further, but I'd still rather ARM over x64. Well, ARMv8, once it's out. Mar 10 04:46:24 The fact that most ARM software still gets compiled without hardware floating point is a problem. But some have VFPv3 some have NEON, some have half the registers of VFP. Mar 10 04:46:45 And a bunch of it doesn't get used. Mar 10 04:48:15 Like x64 was, v8 is a fresh start. Mar 10 06:30:13 why wouldn't you use hardware FP if you have support for it in the chip you are using? Mar 10 06:30:31 Or is it because different ARM chips have different FPUs? Mar 10 06:42:48 Most OSes use hardware FP, but they use softfp ABI to pass arguments to/from functions. Mar 10 06:46:13 SHR: 03shr-devel 07buildhistory * r6481b2fe6e71 10/packages/nokia900-oe-linux-gnueabi/ (9 files in 9 dirs): Build 201203100131 of shr 20120310 for machine nokia900 on opmbuild Mar 10 06:50:00 why use softfp ABI? Mar 10 06:50:14 if the target hardware supports hardfp Mar 10 06:50:57 I guess because binaries built for that platform may not run on things that have hardfp always Mar 10 06:52:24 jonwil: i think that's mainly to allow "soft" to run on "softfp". Mar 10 06:52:59 I.e. if you have a -mfloat-abi=soft application you can still run it on -mfloat-abi=softfp distro. Mar 10 06:53:22 And for hardfp you'd need to rebuild the whole distro. Mar 10 08:20:58 SHR: 03shr-devel 07buildhistory * r86ee1fcaa6cb 10/packages/ (16 files in 16 dirs): Build 201203100916 of shr 20120310 for machine palmpre on opmbuild Mar 10 08:27:38 SHR: 03shr-devel 07buildhistory * r9c1ad9521f0a 10/packages/armv7a-vfp-neon-oe-linux-gnueabi/midori/ (45 files in 45 dirs): Build 201203100925 of shr 20120310 for machine palmpre on opmbuild Mar 10 10:36:12 in current shr-core gta02 (033) the accelerometer doesn't work fine Mar 10 10:36:25 cannot use mokomaze :/ Mar 10 10:36:38 rines: which kernel? Mar 10 10:36:54 2.6.39.4 Mar 10 10:37:27 rines: then accelerometers are really not the largest problem Mar 10 10:37:37 :D Mar 10 10:37:50 rines: there's a suspend issue too Mar 10 10:38:00 oh yes, I know.. Mar 10 10:38:04 docs.openmoko.org seems to be down so I can't give you a link Mar 10 11:04:08 SHR: 03shr-devel 07buildhistory * r277513e93db8 10/packages/palmpre2-oe-linux-gnueabi/ (9 files in 9 dirs): Build 201203101141 of shr 20120310 for machine palmpre2 on opmbuild Mar 10 12:37:03 SHR: 03shr-devel 07buildhistory * r554efac3bfaa 10/ (12 files in 10 dirs): Build 201203101251 of shr 20120310 for machine crespo on opmbuild Mar 10 14:25:06 SHR: 03shr-devel 07buildhistory * r47c784f1659e 10/packages/armv4t-oe-linux-gnueabi/ (52 files in 52 dirs): Build 201203101402 of shr 20120310 for machine om-gta02 on opmbuild Mar 10 19:24:54 SHR: 03shr-devel 07buildhistory * r5fb909f5d54c 10/packages/armv4t-oe-linux-gnueabi/gcc/ (cpp/latest gcc-dbg/latest gcc-dev/latest gcc/latest): Build 201203101951 of shr 20120310 for machine om-gta02 on opmbuild Mar 10 20:47:51 hi dos11 Mar 10 20:49:25 GNUtoo: hi Mar 10 20:49:33 hi Mar 10 20:49:38 GNUtoo: i got uboot running on sgs2 and it blinks camera led Mar 10 20:49:47 chainloaded? Mar 10 20:49:49 yep Mar 10 20:49:53 ok nice Mar 10 20:50:08 any way to run it natively? Mar 10 20:50:36 you need PBL first it seems right? Mar 10 20:50:39 probably. but i need to get a usb<>ttl uart convertor first. kind of difficult to debug without uart Mar 10 20:50:54 ok Mar 10 20:51:03 actually you can build it as a SPL (pbl, that is. with a fixed hardcoded entry point) Mar 10 20:51:07 I've that for crespo Mar 10 20:51:54 can you have bootrom->u-boot->linux kernel? Mar 10 20:52:02 you know, i love free software but i'm not mad about it. right now i don't quite know how exynos boots and don't want to brick it, so i'll chainload Mar 10 20:52:19 yes for you it's ok Mar 10 20:52:34 but if I want to port u-boot myself on crespo it's different Mar 10 20:53:05 i was unable to boot linux. i seem to enable regulators for mmc, but without uart i can't see much. i can fall back to debugging with led, but.. not today Mar 10 20:53:17 ok Mar 10 20:53:34 why serial is not an option for you? Mar 10 20:53:42 it's really easy to do a cable Mar 10 20:54:49 GNUtoo: i left my cable at home and don't have soldering iron here at the dorm. gotta go buy one tomorrow Mar 10 20:56:06 ok Mar 10 21:00:40 it's a pity uboot doesn't have support for samsung framebuffer. which makes me wonder - if i just hardcode fb address and timings, why won't the generic driver work Mar 10 21:01:51 hmmm Mar 10 21:23:12 hmmm Mar 10 21:23:37 looks like my plan works. i see some crap on the screen. probably wrong color format. need to try rgb565 Mar 10 21:24:30 isn't it bgra (8888) ? Mar 10 21:24:59 that's what nexus s, galaxy s and galaxy tab are Mar 10 21:25:06 paulk-desktop: i dunno. i have not checked what it is in linux. uneducated unscientific methodology Mar 10 21:25:12 indeed Mar 10 21:25:18 it is easy to spot on the kernel code Mar 10 21:25:59 paulk-desktop: i wanted to ask one thing. nexus s and galaxy s have the same modem but one uses dpram and the other does not, right? Mar 10 21:26:53 Alex[sp3dev], I don't know for sure the transport layer between SoC and modem, but the kernel drivers sure are different and galaxy s relies on onedram for some reason Mar 10 21:27:17 seems like in both cases, transport is over some shared memory Mar 10 21:27:33 (there is a map of that memory on some header file in galaxy s driver source) Mar 10 21:27:53 but I can't tell for sure Mar 10 21:28:50 paulk-desktop: how's sgs2 research going on? i'm sorry, but i don't understand how it works. do we need to upload firmware and is AT interface available on exynos uarts? or only proprietary transport over hldc in svnet? Mar 10 21:29:48 Alex[sp3dev], I think that AT thing is just some software Mar 10 21:30:00 YAY, got framebuffer console Mar 10 21:30:01 that is "converting" AT to IPC Mar 10 21:30:07 nice Mar 10 21:30:45 Alex[sp3dev], basically, when you type on the available-from-pc serial line that does speak AT, what you are typing is shown on logcat -b main Mar 10 21:31:18 like "read %d bytes: '[...]'" Mar 10 21:31:29 [...] being what you typed Mar 10 21:31:36 so I doubt it's a real serial line to the modem Mar 10 21:31:57 but more some software interfacing between IPC and the USB connection Mar 10 21:32:01 ok. i don't mind any kind of transport. i just have not tried sniffing the boot process Mar 10 21:32:31 Alex[sp3dev], about that, grindars made good progress but it is not working yet IIRC Mar 10 21:32:41 his code is on github Mar 10 21:33:02 only bootup process is a problem, transport should be rather simple Mar 10 21:33:11 his code is there: https://github.com/grindars/freeril-i9100 Mar 10 21:34:01 ok, thanks. i think i'll finish uboot first and try to figure out why suspend doesn't resume and mali400 driver hangs on linaro tree. for modem and sound i'll wait for ICS because i hope they've rewritten the drivers a bit for 3.X kernels Mar 10 21:34:07 paulk-desktop, yes pnatd does it for n900 for instance Mar 10 21:34:19 it's a proprietary daemon which translates isi in AT Mar 10 21:34:38 I guess such thing are needed for exporting the phone over bluetooth Mar 10 21:34:39 GNUtoo, that seems to be the sort of think that is in SGS2(s android Mar 10 21:35:03 or maybe because users were complaining about not being able to control the phone via usb Mar 10 21:35:27 I remember that some old phones permitted to access AT serial from PC when USB was plugged Mar 10 21:35:45 yes some do Mar 10 21:36:02 altough the only dumb phone that still works that I have is a C155 Mar 10 21:36:12 for osmocom-bb/nuttx Mar 10 21:36:59 I took the ones I found to train on soldering Mar 10 21:37:08 paulk-desktop, btw there is someone in #fsf that took an assembly course and really want to reverse some firmwares Mar 10 21:37:12 (when they were going to be trashed) Mar 10 21:37:21 ok Mar 10 21:37:21 ah, nice Mar 10 21:39:09 too bad there are no real alternatives to ida. objdump is too time consuming **** ENDING LOGGING AT Sun Mar 11 02:59:58 2012