Re: Damn... 8GB dead
Paul escreveu: Urgh. Somehow I managed to destroy my 8GB card... I wanted to try Hackable on it, but on the FR there's no mkfs.vfat, and the Linux box won't recognise the card anymore except as a floppy-drive... [...] I guess something's very sour with that card. I do not know if it is the case, but I just saw an interesting message on linux-kernel from H. Peter Anvin: I have seen flash cards die permanently from having a partition table it didn't like written to it. Yes, the microcontroller on the flash card tried to interpret the partition table, assumed to be MS-DOS style, and would crash. http://lkml.org/lkml/2008/12/2/212 -- Cesar Eduardo Barros ces...@cesarb.net cesar.bar...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Overview of all distros
Christian Weßel escreveu: Is there an overview with prerequsist and pro/con of each in wiki? How should I decide which distro could be my one? http://wiki.openmoko.org/wiki/Distributions -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FR won't boot without going into uboot menu first
nickd escreveu: your splash.gz and maybe your uboot-env. I got both of a friend, which worked, but apparently your uboot-env has a list of bad blocks in it written at manufacturing time specifically for your phone. Debug board No, the bad block list is not on the u-boot environment. The bad block list is in a different hidden area, which doesn't show up as a partition and thus is a bit harder to damage (it's in the four fake bad blocks at the very end of the NAND flash). There's another hidden area, in the OOB bytes of the first NAND block, which points to the u-boot environment. If the partitioning is different (and the partitions are stored in the u-boot environment), it has to be adjusted to point to the u-boot environment (else u-boot cannot find it). For more details, take a look at http://wiki.openmoko.org/wiki/NAND_bad_blocks (which was written for the GTA01, but AFAIK the only relevant change for the GTA02 is the addition of the NOR flash and different partition sizes). -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GsmBluetooth state file for gta02
Jim Morris escreveu: Cesar Eduardo Barros wrote So, you just need to find out: - How to switch bluetooth audio I/O to these PCM pins (should be something in the HCI-USB standard). I think bluez driver already does that. I made it work on my PC for instance. Your PC probably doesn't use that mode. It probably sends the audio via the USB interface (which, if you use a USB BT dongle, is the only way available). -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Build Openmoko on FreeBSD
Mr. Morph escreveu:
Hello everybody,
I tried to build the openmoko images on FreeBSD64. I tried it several
time with different images (ASU,FSO and SHR) but everytime I get errors
from bitbake like this:
Buildserver_OpenMoko# sh build-unstable.sh
. conf/topdir.conf test `pwd` = $TOPDIR || echo TOPDIR='`pwd`'
conf/topdir.conf
. ./setup-env; exec bitbake shr-image
NOTE: Handling BitBake files: \ (4430/5704) [77 %]ERROR: Information not
available for target 'amd64-freebsd'
NOTE: type 'exceptions.TypeError':argument of type 'NoneType' is not
iterable while evaluating:
[EMAIL PROTECTED](d)}
NOTE: type 'exceptions.TypeError':argument of type 'NoneType' is not
iterable while evaluating:
[EMAIL PROTECTED]('SITEINFO_ENDIANESS', 'le', '-DL_ENDIAN',
'-DB_ENDIAN', d)} -DTERMIO -fexpensive-optimizations
-frename-registers -fomit-frame-pointer -Os -Wall
[...]
${@'${CFLAG}'.replace('-O2', '')}
ERROR: argument of type 'NoneType' is not iterable while parsing
/shr/shr-unstable/openembedded/packages/openssl/openssl-native_0.9.7g.bb
NOTE: Handling BitBake files: \ (5704/5704) [100 %]
NOTE: Parsing finished. 5450 cached, 0 parsed, 251 skipped, 0 masked.
ERROR: Parsing errors found, exiting...
gmake: *** [image] Error 1
Everyone got some hints for me?
This error is from openembedded/classes/siteinfo.bbclass, called from
openembedded/packages/openssl/openssl.inc. It means what it says: it has
no information about amd64-freebsd, or in fact anything at all besides
Linux (and one instance of Darwin on ARM).
--
Cesar Eduardo Barros
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: why much cpu-time for SDIO Helper
Harald Koenig escreveu: Hi, why does [SDIO Helper] get quite some CPU time without really using the SD card (it's mounted, but I don't access/use it at all...) : [EMAIL PROTECTED]:~# uptime 11:55:17 up 2 days, 13:50, 3 users, load average: 2.65, 5.16, 6.47 [EMAIL PROTECTED]:~# ps up 301 USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 301 1.8 0.0 0 0 ?S Aug29 68:30 [SDIO Helper] Isn't SDIO used for the Wifi chip on the GTA02? (The SD card is on the Glamo IIRC.) -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: AT%N0187 openmoko echo patch?
NeilBrown escreveu: On Mon, September 1, 2008 6:59 pm, Yorick Moko wrote: On Mon, Sep 1, 2008 at 10:43 AM, Lorn Potter [EMAIL PROTECTED] wrote: They certainly are not in our copy of the calypso spec's that we got directly from TI. If it is, I must be missing it, and haven't found it. Maybe TI just wants their products to suck? What I mean: is this standard practice in this business? What possible gain would TI have with not giving you that information? They could avoid having to pay the extra cost of getting a competent and thorough documentation writer? Never attribute to malice that which can be adequately explained by incompetence!! You can have other explanations which are neither malice nor incompetence. - That command might be broken or incomplete in some way, so it's not documented. - That command might be meant for internal debugging only, so it's not documented. I came up with these two in less than a minute. We can probably easily think of other valid justifications. -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GsmBluetooth state file for gta02
Jim Morris escreveu: Cesar Eduardo Barros wrote: Jim Morris escreveu: One thing that may help, is if someone could provide a mapping of the wolfson registers as documented in the WM8753L pdf to the alsa controls. Someone had to have written the code that twiddles the registers in that chip, and would know which also control matches which register. That would be sound/soc/codecs/wm8753.c and sound/soc/s3c24xx/neo1973_gta02_wm8753.c on the kernel source code. Take a look: http://git.openmoko.org/?p=kernel.git;a=blob;f=sound/soc/codecs/wm8753.c;hb=stable http://git.openmoko.org/?p=kernel.git;a=blob;f=sound/soc/s3c24xx/neo1973_gta02_wm8753.c;hb=stable The mapping is there, you only have to find out how it's described. Thanks for the pointers. Thats 2,000 lines of code that is about as clear as mud! (and I've written audio drivers before). There is no mention of Bluetooth in these drivers, and no indication how to switch into bluetooth mode. That's because the Bluetooth is in another chip. For that, you need the full schematics: http://downloads.openmoko.org/schematics/GTA02/Schematics_Freerunner-GTA02_A5-A7cumulative_public_RC0.pdf The very first diagram (page 2) shows how the chips fit together. There you can see how the bluetooth chip is connected to the codec: the PCM pins. There seems to be a comment saying something about BT Codec DAI on neo1973_gta02_wm8753.c, which seems related. So, you just need to find out: - How to switch bluetooth audio I/O to these PCM pins (should be something in the HCI-USB standard). - How to route within the codec between the PCM pins and the pins which are connected to the GSM chip (these pins are also shown in the diagram). A possible hint: back when trying to find out why the GTA01 used too much power when off, we had to find how to turn off the audio amp (another chip). I saw a concept called a scenario, which is some sort of predefined audio routing on the kernel. So perhaps you just have to find the correct scenario and how to select it. On neo1973_wm8753.c, it's the Neo Mode control; for some very strange reason, there's no equivalent on neo1973_gta02_wm8753.c, however the defines are still there in the top of the file! I really don't see how we are supposed to figure this stuff out, without any help from Openmoko. With the schematics. That's one of the reasons they were released. With them, the detailed datasheet for the chips, and the kernel source code, you can do a lot. -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GsmBluetooth state file for gta02
Jim Morris escreveu: One thing that may help, is if someone could provide a mapping of the wolfson registers as documented in the WM8753L pdf to the alsa controls. Someone had to have written the code that twiddles the registers in that chip, and would know which also control matches which register. That would be sound/soc/codecs/wm8753.c and sound/soc/s3c24xx/neo1973_gta02_wm8753.c on the kernel source code. Take a look: http://git.openmoko.org/?p=kernel.git;a=blob;f=sound/soc/codecs/wm8753.c;hb=stable http://git.openmoko.org/?p=kernel.git;a=blob;f=sound/soc/s3c24xx/neo1973_gta02_wm8753.c;hb=stable The mapping is there, you only have to find out how it's described. -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Current daily snapshots under QEMU
Patryk Cisek escreveu: Hi, It seems like recently daily snapshots don't work on QEMU: http://buildhost.openmoko.org/daily/neo1973/200808/ I tried 20080801 and 20080802. After downloading rootfs, kernel image and u-boot, I flashed qemu with openmoko/flash.sh. After booting it (openmoko/qemu-auto.sh) bootmenu shows up. After clicking Boot, splash screen shows for a little while and boot menu comes again. Any ideas? I tried some snapshots from buildhost.openmoko.org before they were wiped out and 2007.2 worked fine. At least the ones I tried. I had the same problem (but with self-built images from Mokomakefile), and it started working when I replaced the u-boot with the trusty old august snapshot u-boot I still use in the real device. -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: building minimo Re: PyGTK- installation?
arne anka escreveu: to the existing bb recipe. (the next make update will fail because mokomakefile or oe fails to either respect or simply overwrite the recipe, for what reason ever). To make mokomakefile respect your change (including automatically merging it when needed), just commit it (the openembedded directory is a normal git working tree). Mokomakefile does a sequence where it will merge your local changes instead of overwriting them, but it fails without a clean working tree (i.e. you cannot have uncommited changes; see http://www.kernel.org/pub/software/scm/git/docs/gitglossary.html for details). this will immediately make you hit another snag: In file included from js/jsarena.c:49: js/jsbit.h:173: error: size of array 'js_static_assert_line_173' is negative make[1]: *** [js/jsarena.o] Error 1 make: *** [src] Error 2 go to jsbit.h line 173 and kill one long from [2] JS_STATIC_ASSERT(sizeof(unsigned long long) == sizeof(JSUword)); i am no c genius but i suppose minimo/firefox defines unsigned long long in some incompatible way -- i sincerely hope unsigned long is still long enough (can somebody shed some light?) anyway, after this minimo builds even on amd64. Defeating a static assert is not a good idea (size of array is negative is what happens when a static assert fails). The assert being there probably means the programmers assumed sizeof(unsigned long long) == sizeof(JSUword) in the code, and wanted the build to abort in case something went wrong and that wasn't true. The real error should be elsewhere, in the definition of JSUword (it should have the same size as unsigned long long (i.e. 64 bits), but not necessarily the same type). Since you are on arm, unsigned long is probably 32 bits, which means the variable has half the size it should have. I'm guessing it's confusing native and cross compilers; it is using the native compiler to find out that unsigned long is enough (64 bits on the AMD64 architecture), but using the cross compiler to actually compile the code (where unsigned long is 32 bits). -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Steve on V5 versus v6
Dylan Semler escreveu: Wait, no guitar pick? Shouldn't you get the guitar pick with the debug board, since its main use is to plug the debug board? It makes more sense than putting it in the phone box. This, of course, leads to a separate question: what will ship in the debug board's box? It should have more free space in the box, since the board is smaller than the phone. -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Steve on V5 versus v6
Tilman Baumann escreveu: Antoine Reid wrote: Don't you need to open the case to insert the battery, the SIM card and the SD card? Or am I mistaken here? Do you need to remove another panel to get to the debug board connector? This was at least so with the Neo 1973. The battery, SIM and MMC compartment is easily to open with bare fingers. (Really, you don't need the guitar pick) If you lost your fingernails in a horrible freak accident or any other reason, you could use anything else thin. :) Going down to the debug port needs a torx screwdriver anyway. The guitar pick is a nice nerdy idea. But completely useless. *g* Getting to the debug port, at least as described in the wiki, needs both the torx screwdriver and the guitar pick. You are opening the front cover for that, not the back cover (which can be opened with your fingers alone, and is where the battery is). See http://wiki.openmoko.org/wiki/Disassembling_Neo1973#Carefully_remove_top_cover for the details. -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
